* Re: MPC8555 USB host support
From: Kumar Gala @ 2005-11-16 15:50 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <437A016C.8070405@ru.mvista.com>
Hmm, we should understand what caveats it has and still look at
getting it into mainline.
Also, are you aware of Freescale's driver for this?
- kumar
On Nov 15, 2005, at 9:40 AM, Vitaly Bordug wrote:
> Kumar Gala wrote:
>> Any reason not to get this driver into the kernel main line?
> I guess because this device is known to work in some specific
> instance, but bot generic one. The best we can do is to consolidate
> our efforts to make it more usable or state that it is impossible.
>
>> - kumar
>> On Nov 15, 2005, at 12:59 AM, Mike Rapoport wrote:
>>> Hans Schillstrom wrote:
>>>
>>>> Hi Mike
>>>> I'm working with a 8270 board and 2.6.12 kernel and searching
>>>> for USB
>>>> drivers.
>>>>
>>>> Could you help me finding the files ?
>>>>
>>> I've opened a project on the SourceForge, http://
>>> cpm2usb.sourceforge.net. The file containing patch against
>>> 2.6.12.3 can be downloaded at http://sourceforge.net/projects/
>>> cpm2usb.
>>>
>>>> I can help you with the testing.
>>>> What status do they have right now ?
>>>>
>>> The driver was developed on MPC8272ADS, but should go as well on
>>> 8270 since they have the same USB host controller AFAIK.
>>> Currently, as far as I tested it works fine with full-speed
>>> single device attached through hub, but fails is there are
>>> transfers from/to several devices simultaneously.
>>> As for the code itself, it's far from being perfect.
>>>
>>>> Regards Hans
>>>>
>>>
>>>
>>> --Sincerely yours,
>>> Mike Rapoport
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> --
> Sincerely,
> Vitaly
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: Kumar Gala @ 2005-11-16 15:24 UTC (permalink / raw)
To: David Woodhouse; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <1132136755.21643.40.camel@hades.cambridge.redhat.com>
On Nov 16, 2005, at 4:25 AM, David Woodhouse wrote:
> On Wed, 2005-11-16 at 20:12 +1100, Paul Mackerras wrote:
>> Yes, it works on newworld (at least it does on my G4 powerbook). It
>> should work on 32-bit CHRP with any luck, but for oldworld we'll have
>> to generate a COFF file.
>
> I'll try it on Pegasos some time tonight or tomorrow. AFAICT I'm going
> to need the patch which started this thread, if I want any serial
> ports
> on my Pegasos. The newly-created asm-powerpc/serial.h file is
> devoid of
> serial port definitions.
>
> Here it is again, with Tom's three criticisms addressed, deliberately
> ignored, and addressed. In that order.
>
> It no longer touches asm-ppc/serial.h, so doesn't break the legacy
> zImage.
>
> ---
> [PATCH] Fix 8250 probe on ppc32
>
> There are no serial ports defined in the new asm-powerpc/serial.h, and
> rightly so. The 64-bit setup code has a routine to look in the device
> tree for them and register a platform_device for any we find there;
> this
> patch steals that routine and makes it available on 32-bit machines
> too...
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
>
[snip]
> --- linux-2.6.13/drivers/serial/Kconfig.sof 2005-10-20
> 12:54:48.000000000 +0100
> +++ linux-2.6.13/drivers/serial/Kconfig 2005-10-20
> 13:05:39.000000000 +0100
> @@ -77,6 +77,11 @@ config SERIAL_8250_CS
>
> If unsure, say N.
>
> +config SERIAL_8250_OF
> + bool
> + default y
> + depends on PPC_OF && SERIAL_8250 && PPC_MERGE
> +
> config SERIAL_8250_ACPI
> bool "8250/16550 device discovery via ACPI namespace"
> default y if IA64
[snip]
Should this really depend on PPC_OF? Does it require true
OpenFirmware or just a flat dev tree to work?
I ask because I'd like to extended this in the future to handle 8250
serial ports that aren't on a PCI or ISA bus, but on SoCs like 83xx,
85xx, 86xx, 4xx? These will most likely not be running with true OF
but I've got a flat dev tree working today.
The following is what I've been toying with for an description of the
8250 node (in .dts format):
serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>;
clock-frequency = <0>;
interrupts = <1a 3>;
interrupt-parent = <40000>;
};
- kumar
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Kumar Gala @ 2005-11-16 15:15 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <20051116093609.GA26269@iram.es>
On Nov 16, 2005, at 3:36 AM, Gabriel Paubert wrote:
> On Tue, Nov 15, 2005 at 08:19:58PM -0600, Becky Bruce wrote:
>> Ben,
>>
>> Yeah, I clearly shouldn't run testcases at 11pm, because I got in a
>> rush and only confirmed that lmw/stmw were actually taking the
>> exception. Those 2 are working beautifully. To test the others, I
>> need to run on a different board which, of course, isn't bootable at
>> the moment. As soon as I can get that up and running, I'll try
>> some of
>> the other cases and let you know how it goes......
>>
>> BTW, Based on the pile of docs I have here, I think the list of
>> alignment-exception-causing events on FSL's current parts (603, 603e,
>> 750, 74x, 74xx, e500) is:
>
> The 603 is still in production? And is the upcoming 8641 exactly
> the same as the 74xx series in this respect?
603 is used in all 82xx/83xx processors from Freescale. The 8641 is
the same core as 7448.
>> - single and double precision floating point ld/st ops (non-E500, non
>> data size aligned)
>
> Hmm, you can load a double from any 4 byte aligned address AFAIR.
This is only because every processor handles the misalignment for
you. Its completely valid for someone to build a PPC that has an
alignment exception in this case.
>> - dcbz to WT or CI memory (all procs)
>> - dcbz with cache disabled (all procs but 603e?)
>> - misaligned little endian accesses (603e)
>
> I understand that you mention it for completeness since we
> don't care about LE mode AFAICT. But I believe that there
> were some differences between 603 and 603e in this area.
>
> However we do care about byte reversal instructions, which
> probably believe like the corresponding normal instruction
> (i.e., lwbrx has the same rules as lwzx, etc.)
>
>> - lwarx/stwcx (all procs)
>
> And ldarx/stdcx. on 64 bit, but these ones should not
> be emulated. So it's easy ;-)
>
>> - multiple/string with LE set (750, 603e, 7450, 7400)
>
> Again LE mode is probably irrelevant.
Agree with that. We dont support LE on classic.
>> - eciwx/ecowx (750, 7450, 7400)
>
> Have these instructions ever been used for something
> under Linux?
I dont believe so.
>> - a couple of others related to vector processing
>
> Which ones? The Altivec load and store instructions
> simply mask the low order bits AFAIR.
SPE misalignment is something to look at.
>> If anybody knows offhand of something missing there, let me know.
>
> Nothing, but did you check when crossing a segment (256MB) boundary.
> I seem to remember that some processors performed misaligned
> load/store across pages but not across segments.
- kumar
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-16 8:39 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: 'Tom Rini', 'Dan Malek', gtolstolytkin,
linuxppc-embedded
In-Reply-To: <TMNT04NwMmRDltJmBYW0000000a@tmnt04.transmode.se>
On Sun, Nov 13, 2005 at 01:47:53PM +0100, Joakim Tjernlund wrote:
>
>
> > -----Original Message-----
> > From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> > Sent: den 12 november 2005 20:28
> > To: Joakim Tjernlund
> > Cc: Tom Rini; Dan Malek; gtolstolytkin@ru.mvista.com;
> > linuxppc-embedded@ozlabs.org
> > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> >
> > On Mon, Nov 07, 2005 at 07:37:45PM +0100, Joakim Tjernlund wrote:
> > > >
> > > > On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:
> > > > > > -----Original Message-----
> > > > > > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > > > > > Sent: 07 November 2005 16:52
> > > > > > To: Marcelo Tosatti
> > > > > > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > > > > > linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> > > > > > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> > > > > >
> > > > > > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo
> > Tosatti wrote:
> > > > > > > Joakim!
> > > > > > >
> > > > > > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim
> > > > Tjernlund wrote:
> > > > > > > > Hi Marcelo
> > > > > > > >
> > > > > > > > [SNIP]
> > > > > > > > > The root of the problem are the changes against the 8xx
> > > > > > > > > TLB handlers introduced during v2.6. What
> > happens is the
> > > > > > > > > TLBMiss handlers load the zeroed pte into the
> > TLB, causing
> > > > > > > > > the TLBError handler to be invoked (thats two
> > TLB faults
> > > > > > > > > per pagefault), which then jumps to the generic
> > MM code to
> > > > > > setup the pte.
> > > > > > > > >
> > > > > > > > > The bug is that the zeroed TLB is not invalidated (the
> > > > > > same reason
> > > > > > > > > for the "dcbst" misbehaviour), resulting in infinite
> > > > > > TLBError faults.
> > > > > > > > >
> > > > > > > > > Dan, I wonder why we just don't go back to v2.4
> > behaviour.
> > > > > > > >
> > > > > > > > This is one reason why it is the way it is:
> > > > > > > >
> > > > > >
> > > >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.ht
> > > > ml
> > > > > > > > This details are little fuzzy ATM, but I think the
> > > > reason for the
> > > > > > > > current
> > > > > > > > impl. was only that it was less intrusive to impl.
> > > > > > >
> > > > > > > Ah, I see. I wonder if the bug is processor specific: we
> > > > > > don't have such
> > > > > > > changes in our v2.4 tree and never experienced such problem.
> > > > > > >
> > > > > > > It should be pretty easy to hit it right? (instruction
> > > > > > pagefaults should
> > > > > > > fail).
> > > > > > >
> > > > > > > Grigori, Tom, can you enlight us about the issue on the URL
> > > > > > above. How
> > > > > > > can it be triggered?
> > > > > >
> > > > > > So after looking at the code in 2.6.14 and current git, I
> > > > think the
> > > > > > above URL isn't relevant, unless there was a change I
> > > > missed (which
> > > > > > could totally be possible) that reverted the patch there and
> > > > > > fixed that issue in a different manner. But since I didn't
> > > > > > figure that out until I had finished researching it again:
> > > > >
> > > > > I wasn't clear enough. What I meant was that the above
> > patch made
> > > > > me think and the result was that I came up with a
> > simpler fix, the
> > > > > "two
> > > > exception"
> > > > > fix that
> > > > > is in current kernels. See
> > > > >
> > > > http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/h
> > > > ead_8xx.S@
> > > > >
> > > > 1.19?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/k
> > > > ernel|hist
> > > > > /arch/ppc/kernel/head_8xx.S
> > > > > It appears this fix has some other issues :(
> > > > >
> > > > > How do the other ppc arches do? I am guessing that they don't
> > > > > double fault, but bails out to do_page_fault from the TLB Miss
> > > > > handler, like 8xx used to do.
> > > >
> > > > Assuming Dan doesn't come up with a more simple & better
> > fix, maybe
> > > > we should go back to the original patch I made?
> > >
> > > That was what I was thinking too(or some variation of your patch) I
> > > wonder if that would solve the misbehaving dcbst problem
> > Marcelo found
> > > some time ago too?
> >
> > Hi Joakim,
> >
> > Yes, it would fix the "dcbst" issue. That problem was
> > triggered by a zeroed TLB entry.
> >
> > In practice it seems that the "three exception" approach does
> > not impose a significant overhead in comparison with the "two
> > exception" version (as can be seen by the results of the
> > latency tests).
> >
> > Anyway, if decided upon, the "two exception" version (no
> > zeroed TLB entry state) needs the TLBMiss handler should to
> > the present bit as Dan mentioned.
> >
> > I don't know what Dan is up to, he meant to be doing
> > significant changes.
> >
> > I'll be playing with TLB preloading next week... how's your
> > TLB handler shrinkage idea?
>
> Hi Marcelo
>
> Its still holding I think, it's a add on to whats in linuxppc-2.4:
> http://ppc.bkbits.net:8080/linuxppc-2.4/diffs/arch/ppc/kernel/head_8xx.S@1.21?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/pp
> c/kernel|hist/arch/ppc/kernel/head_8xx.S
>
> If one could eliminate the test for a zero L1 entry you save an extra 4 instructions.
> + mfcr r20
> + cmplwi cr0, r21, 0x0fff /* Test page descriptor page address */
> + bng- 2f /* If zero, don't try to find a pte */
> + mtcr r20
>
> If SPRG2 is free to use you can stash r21 there, then you don't need to use RAM to stash registers.
>
> Maybe its possible to PIN some of the vmalloc space and use that for modules?
Sure it is. That could be part of the logic to fault large pages for the kernel
address space when possible.
^ permalink raw reply
* Re: [PATCH] m8xx_wdt: software watchdog reset/interrupt select
From: Marcelo Tosatti @ 2005-11-16 8:36 UTC (permalink / raw)
To: Florian Schirmer; +Cc: obi, carjay, linux-ppc-embedded
In-Reply-To: <437B1C53.1060004@tuxbox.org>
On Wed, Nov 16, 2005 at 12:47:31PM +0100, Florian Schirmer wrote:
> Hi,
>
> >>The SYPCR register can be set only _once_ at machine startup and the
> >>bootloader in question does not have an option to change the mode. Many
> >>bootloaders probably dont.
>
> Okay, i was asuming you have control over the bootloader.
>
> >Updated patch addresses code duplication issue you mentioned and also
> >adds an error message in case timer interrupt frequency is higher
> >than the watchdog frequency.
> >
> >Can I add your Signed-off-by in case you're OK with it?
>
> Maybe i'm missing something obvious, but why is the interrupt driven
> reaming code not working for your configuration. Are you using the PIT
> for something else?
Nope.
Anyway, the SWRI bit selects interrupt (0) or reset mode (1) for the watchdog.
On reset mode no interrupt is sent to the kernel - the watchdog logic resets
the system with HRESET.
So, the timer in m8xx_wdt is _required_ for reset mode.
Does that make sense?
> Otherwise i'm fine with the patch. Feel free to add my Signed-off-by line.
Ok, lets sort this out first.
I wonder how interrupt mode is supposed to work, because the manual states
that in interrupt mode (SWRI == 0) an NMI (IRQ0) is triggered, which jumps
to 0x100 exception vector (SW reset).
Maybe I'm misunderstanding the interrupt mode?
Folks who wrote the patch claim it works on their 8xx's (as can be found
on mailing list archives).
^ permalink raw reply
* 11-16-05 2.6.14 on AMCC Yosemite board(PCI-IDE card boot error)
From: KylongMu @ 2005-11-16 12:18 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 1256 bytes --]
Dear Denk,
Thanks for your help; it makes my Yosemite run up! I'm try to add a
PCI-IDE
Card on it. I test my Promise-PDC20268 card and AEC6280 (ATP865-B chip type)
card,
Both of them all failed with same error, the boot message included in the
attachment.
The kernel configure is based on the Yosemite_defconfig, add with:
Device Drivers-->
ATA/ATAPI/MFM/RLL support-->
[*]AEC62XX Chipset support
[*]PROMISE
PDC202{68|69|70|71|75|76|77} SUPPORT
Both of the PCI-IDE cards can work with X86PC+FEDORA4 configure, I
don't know
What cause them fail on Yosemite with final 2.6.14 kernel.
About my 2.6.14 tree, I type with "cg-log -s" command it shows:
99a21389c2b0e55f30b6cf6550cb492b87dbaa3b Heiko Schocher 2005-11-11 12:47
[PATCH] ppc32: fix Kernel Panic for PM82x Board with gcc-4.0.
ff1df84b3c3154ffdb646941e1c70d17554e3042 Wolfgang Denk 2005-11-10 00:41
Merge with /home/wd/git/linux-2.6/stefan_roese
It only shows 2.6.14 on the kernel message, I don't know why it doesn't
show the message as you told.
But it can work, and fixed the bugs on Yosemite.
Cordially,
Kylong Mu
[-- Attachment #1.2: Type: text/html, Size: 10598 bytes --]
[-- Attachment #2: bootmessage(acard6280 pci-ide card).txt --]
[-- Type: text/plain, Size: 6044 bytes --]
U-Boot 1.1.4 (Nov 11 2005 - 19:35:30)
AMCC PowerPC 440EP Rev. B
Board: Yosemite - AMCC PPC440EP Evaluation Board
VCO: 1066 MHz
CPU: 533 MHz
PLB: 133 MHz
OPB: 66 MHz
EPB: 66 MHz
PCI: 66 MHz
I2C: ready
DRAM: 256 MB
FLASH: 64 MB
PCI: Bus Dev VenId DevId Class Int
00 0c 1191 0009 0180 00
In: serial
Out: serial
Err: serial
Net: ppc_4xx_eth0, ppc_4xx_eth1
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 0
=> tftp 400000 uImage
ENET Speed is 100 Mbps - FULL duplex connection
Using ppc_4xx_eth0 device
TFTP from server 192.168.0.93; our IP address is 192.168.0.66
Filename 'uImage'.
Load address: 0x400000
Loading: #################################################################
#################################################################
#################################################################
###########################################
done
Bytes transferred = 1217393 (129371 hex)
=> bootram
Unknown command 'bootram' - try 'help'
=> run bootram
## Booting image at 00400000 ...
Image Name: Linux-2.6.14
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1217329 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fed40000 ...
Image Name: Yosemite Ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 17770706 Bytes = 16.9 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0ee47000, end 0ff398d2 ... OK
Linux version 2.6.14 (root@dxp) (gcc version 4.0.0) #7 Sun Nov 13 21:59:01 CST 2005
AMCC PowerPC 440EP Yosemite Platform
Built 1 zonelists
Kernel command line: ramdisk_size=49152 root=/dev/ram rw ip=192.168.0.66:192.168.0.93::255.255.255.0:yosemite:eth0:off panic=1 console=ttyS0,115200
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 239616k available (1860k kernel code, 596k data, 140k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
softlockup thread 0 started up.
Freeing initrd memory: 17354k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
usbcore: registered new driver usbfs
usbcore: registered new driver hub
SCSI subsystem initialized
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
usbmon: debugfs is not available
ppc-soc-ohci ppc-soc-ohci.0: USB Host Controller
ppc-soc-ohci ppc-soc-ohci.0: new USB bus registered, assigned bus number 1
ppc-soc-ohci ppc-soc-ohci.0: irq 40, io mem 0xef601000
usb usb1: Product: USB Host Controller
usb usb1: Manufacturer: Linux 2.6.14 ohci_hcd
usb usb1: SerialNumber: PPC-SOC USB
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
pegasus: v0.6.12 (2005/01/13), Pegasus/Pegasus II USB Ethernet driver
usbcore: registered new driver pegasus
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 49152K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
zmii0: bridge in RMII mode
eth0: emac0, MAC 00:10:ec:00:87:40
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:10:ec:00:87:47
eth1: found Generic MII PHY (0x03)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR= 0xfffff7ff
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00000000 LR: C0263628 SP: CFF41F40 REGS: c0271f50 TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = c04f8b10[1] 'swapper' THREAD: cff40000
Last syscall: 120
GPR00: FDFFEF02 CFF41F40 C04F8B10 C04FC000 C026C6B4 C04FC000 00000009 CFF41EF4
GPR08: C04F9F70 00000000 00004000 C0270000 24254322 61000408 0FFB6800 00000001
GPR16: 00800000 0FFCEAD4 FFFFFFFF 00000000 007FFF00 0FFB1210 00000003 00000002
GPR24: C01D0000 C01D0000 C0270000 C01D0000 C0270000 C0223E10 C026C6B4 C04FC000
NIP [00000000] 0x0
LR [c0263628] aec62xx_init_one+0x38/0x48
Call trace:
[c0263628] aec62xx_init_one+0x38/0x48
[c02649b8] ide_scan_pcidev+0x68/0xb0
[c0264a34] ide_scan_pcibus+0x34/0xe8
[c026492c] ide_init+0x68/0x8c
[c00013ac] init+0xb4/0x254
[c00046c0] kernel_thread+0x48/0x64
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR= 0xfffff7ff
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C000235C SP: C0271E70 REGS: c0271f50 TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = c04f8b10[1] 'swapper' THREAD: cff40000
Last syscall: 120
GPR00: 08000000 C0271E70 C04F8B10 C0271E80 00001568 FFFFFFFF C0270000 00004000
GPR08: C0270000 C000235C 00021002 C00039E8 C04F8CD8 61000408 0FFB6800 00000001
GPR16: 00800000 0FFCEAD4 FFFFFFFF 00000000 007FFF00 0FFB1210 00000003 00000002
GPR24: C01D0000 C01D0000 C0270000 C01D0000 C0270000 C0223E10 00000007 C0271F50
NIP [00000000] 0x0
LR [c000235c] ret_from_except+0x0/0x18
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 1 seconds..
^ permalink raw reply
* [PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
From: Vitaly Bordug @ 2005-11-16 12:04 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded list
This adds board-specific files needed to utilize fs_enet Ethernet driver
for MPC885ADS and MPC866ADS.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
arch/ppc/Kconfig | 47 ++++
arch/ppc/platforms/Makefile | 2
arch/ppc/platforms/fads.h | 2
arch/ppc/platforms/mpc866ads_setup.c | 290 ++++++++++++++++++++++++
arch/ppc/platforms/mpc885ads_setup.c | 408 ++++++++++++++++++++++++++++++++++
5 files changed, 748 insertions(+), 1 deletions(-)
create mode 100644 arch/ppc/platforms/mpc866ads_setup.c
create mode 100644 arch/ppc/platforms/mpc885ads_setup.c
applies-to: f358a802ba9f62bb4777d5f626f2972d1b0fa43b
4c4f454bd8e79fd67bc86aa9a22604f66d682d3b
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
index 8fa51b0..8e6fcb2 100644
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -506,6 +506,53 @@ config WINCEPT
endchoice
+menu "Freescale Ethernet driver platform-specific options"
+ depends on FS_ENET
+
+ config MPC8xx_SECOND_ETH
+ bool "Second Ethernet channel"
+ depends on (MPC885ADS || MPC86XADS)
+ default y
+ help
+ This enables support for second Ethernet on MPC885ADS and MPC86xADS boards.
+ The latter will use SCC1, for 885ADS you can select it below.
+
+ choice
+ prompt "Second Ethernet channel"
+ depends on MPC8xx_SECOND_ETH
+ default MPC8xx_SECOND_ETH_FEC2
+
+ config MPC8xx_SECOND_ETH_FEC2
+ bool "FEC2"
+ depends on MPC885ADS
+ help
+ Enable FEC2 to serve as 2-nd Ethernet channel. Note that SMC2
+ (often 2-nd UART) will not work if this is enabled.
+
+ config MPC8xx_SECOND_ETH_SCC1
+ bool "SCC1"
+ depends on MPC86XADS
+ select MPC8xx_SCC_ENET_FIXED
+ help
+ Enable SCC1 to serve as 2-nd Ethernet channel. Note that SMC1
+ (often 1-nd UART) will not work if this is enabled.
+
+ config MPC8xx_SECOND_ETH_SCC3
+ bool "SCC3"
+ depends on MPC885ADS
+ help
+ Enable SCC3 to serve as 2-nd Ethernet channel. Note that SMC1
+ (often 1-nd UART) will not work if this is enabled.
+
+ endchoice
+
+ config MPC8xx_SCC_ENET_FIXED
+ depends on MPC8xx_SECOND_ETH_SCC
+ default n
+ bool "Use fixed MII-less mode for SCC Ethernet"
+
+endmenu
+
choice
prompt "Machine Type"
depends on 6xx || POWER3 || POWER4
diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
index 7c5cdab..cce6487 100644
--- a/arch/ppc/platforms/Makefile
+++ b/arch/ppc/platforms/Makefile
@@ -45,6 +45,8 @@ obj-$(CONFIG_SBC82xx) += sbc82xx.o
obj-$(CONFIG_SPRUCE) += spruce.o
obj-$(CONFIG_LITE5200) += lite5200.o
obj-$(CONFIG_EV64360) += ev64360.o
+obj-$(CONFIG_MPC86XADS) += mpc866ads_setup.o
+obj-$(CONFIG_MPC885ADS) += mpc885ads_setup.o
ifeq ($(CONFIG_SMP),y)
obj-$(CONFIG_PPC_PMAC) += pmac_smp.o
diff --git a/arch/ppc/platforms/fads.h b/arch/ppc/platforms/fads.h
index a48fb8d..e1c0b1b 100644
--- a/arch/ppc/platforms/fads.h
+++ b/arch/ppc/platforms/fads.h
@@ -112,7 +112,7 @@
/* CPM Ethernet through SCC1 or SCC2 */
-#ifdef CONFIG_SCC1_ENET /* Probably 860 variant */
+#if defined(CONFIG_SCC1_ENET) || defined(CONFIG_MPC8xx_SECOND_ETH_SCC1) /* Probably 860
variant */
/* Bits in parallel I/O port registers that have to be set/cleared
* to configure the pins for SCC1 use.
* TCLK - CLK1, RCLK - CLK2.
diff --git a/arch/ppc/platforms/mpc866ads_setup.c b/arch/ppc/platforms/mpc866ads_setup.c
new file mode 100644
index 0000000..6ffdb0e
--- /dev/null
+++ b/arch/ppc/platforms/mpc866ads_setup.c
@@ -0,0 +1,290 @@
+/*arch/ppc/platforms/mpc885ads-setup.c
+ *
+ * Platform setup for the Freescale mpc885ads board
+ *
+ * Vitaly Bordug <vbordug@ru.mvista.com>
+ *
+ * Copyright 2005 MontaVista Software Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/param.h>
+#include <linux/string.h>
+#include <linux/ioport.h>
+#include <linux/device.h>
+
+#include <linux/fs_enet_pd.h>
+#include <linux/mii.h>
+
+#include <asm/delay.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/page.h>
+#include <asm/processor.h>
+#include <asm/system.h>
+#include <asm/time.h>
+#include <asm/ppcboot.h>
+#include <asm/8xx_immap.h>
+#include <asm/commproc.h>
+#include <asm/ppc_sys.h>
+#include <asm/mpc8xx.h>
+
+extern unsigned char __res[];
+
+/* access ports */
+#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) | (_v))
+#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~(_v))
+
+#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) | (_v))
+#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~(_v))
+
+static struct fs_mii_bus_info fec_mii_bus_info = {
+ .method = fsmii_fec,
+ .id = 0,
+};
+
+static struct fs_mii_bus_info scc_mii_bus_info = {
+ .method = fsmii_fixed,
+ .id = 0,
+ .i.fixed.speed = 10,
+ .i.fixed.duplex = 0,
+};
+
+static struct fs_platform_info mpc8xx_fec_pdata[] = {
+ {
+ .rx_ring = 128,
+ .tx_ring = 16,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 15,
+ .phy_irq = -1,
+
+ .use_rmii = 0,
+
+ .bus_info = &fec_mii_bus_info,
+ }
+};
+
+static struct fs_platform_info mpc8xx_scc_pdata = {
+ .rx_ring = 64,
+ .tx_ring = 8,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = -1,
+ .phy_irq = -1,
+
+ .bus_info = &scc_mii_bus_info,
+};
+
+static void mpc866_nonplatform_device_init(void)
+{
+ volatile cpm8xx_t *cp = cpmp;
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR1\n");
+ return;
+ }
+#ifdef CONFIG_SERIAL_CPM_SMC1
+ cp->cp_simode &= ~(0xe0000000 >> 17); /* brg1 */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~(0x80000000 >> 7));
+#else
+ out_be32(bcsr_io, in_be32(bcsr_io) | (0x80000000 >> 7));
+ cp->cp_pbpar &= ~(0x000000c0);
+ cp->cp_pbdir |= 0x000000c0;
+ cp->cp_smc[0].smc_smcmr = 0;
+ cp->cp_smc[0].smc_smce = 0;
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SMC2
+ cp->cp_simode &= ~(0xe0000000 >> 1);
+ cp->cp_simode |= (0x20000000 >> 1); /* brg2 */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~(0x80000000 >> 13));
+#else
+ out_be32(bcsr_io, in_be32(bcsr_io) | (0x80000000 >> 13));
+ cp->cp_pbpar &= ~(0x00000c00);
+ cp->cp_pbdir |= 0x00000c00;
+ cp->cp_smc[1].smc_smcmr = 0;
+ cp->cp_smc[1].smc_smce = 0;
+#endif
+ iounmap(bcsr_io);
+}
+
+static void setup_fec1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+
+ setbits16(immap->im_ioport.iop_pdpar, 0x1fff);
+ setbits16(immap->im_ioport.iop_pddir, 0x1fff);
+}
+
+static void setup_scc1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR1\n");
+ return;
+ }
+
+ /* Enable the PHY.
+ */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~BCSR1_ETHEN);
+
+ /* Configure port A pins for Txd and Rxd.
+ */
+ /* Disable receive and transmit in case EPPC-Bug started it.
+ */
+ setbits16(immap->im_ioport.iop_papar, PA_ENET_RXD | PA_ENET_TXD);
+ clrbits16(immap->im_ioport.iop_padir, PA_ENET_RXD | PA_ENET_TXD);
+ clrbits16(immap->im_ioport.iop_paodr, PA_ENET_TXD);
+
+ /* Configure port C pins to enable CLSN and RENA.
+ */
+ clrbits16(immap->im_ioport.iop_pcpar, PC_ENET_CLSN | PC_ENET_RENA);
+ clrbits16(immap->im_ioport.iop_pcdir, PC_ENET_CLSN | PC_ENET_RENA);
+ setbits16(immap->im_ioport.iop_pcso, PC_ENET_CLSN | PC_ENET_RENA);
+ /* Configure port A for TCLK and RCLK.
+ */
+ setbits16(immap->im_ioport.iop_papar, PA_ENET_TCLK | PA_ENET_RCLK);
+ clrbits16(immap->im_ioport.iop_padir, PA_ENET_TCLK | PA_ENET_RCLK);
+ clrbits32(immap->im_cpm.cp_pbpar, PB_ENET_TENA);
+ clrbits32(immap->im_cpm.cp_pbdir, PB_ENET_TENA);
+
+ /* Configure Serial Interface clock routing.
+ * First, clear all SCC bits to zero, then set the ones we want.
+ */
+ clrbits32(immap->im_cpm.cp_sicr, SICR_ENET_MASK);
+ setbits32(immap->im_cpm.cp_sicr, SICR_ENET_CLKRT);
+
+ /* In the original SCC enet driver the following code is placed at the end of the
initialization */
+ setbits32(immap->im_cpm.cp_pbpar, PB_ENET_TENA);
+ setbits32(immap->im_cpm.cp_pbdir, PB_ENET_TENA);
+
+}
+
+static void mpc866ads_fixup_enet_pdata(struct platform_device *pdev,
+ int fs_no)
+{
+ struct fs_platform_info *fpi = pdev->dev.platform_data;
+
+ volatile cpm8xx_t *cp;
+ bd_t *bd = (bd_t *) __res;
+ char *e;
+ int i;
+
+ /* Get pointer to Communication Processor */
+ cp = cpmp;
+ switch (fs_no) {
+ case fsid_fec1:
+ fpi = &mpc8xx_fec_pdata[0];
+ fpi->init_ioports = &setup_fec1_ioports;
+
+ break;
+ case fsid_scc1:
+ fpi = &mpc8xx_scc_pdata;
+ fpi->init_ioports = &setup_scc1_ioports;
+
+ break;
+ default:
+ break;
+ }
+
+ pdev->dev.platform_data = fpi;
+ fpi->fs_no = fs_no;
+
+ e = (unsigned char *)&bd->bi_enetaddr;
+ for (i = 0; i < 6; i++)
+ fpi->macaddr[i] = *e++;
+
+ fpi->macaddr[5 - pdev->id]++;
+
+}
+
+static void mpc866ads_fixup_fec_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for FEC devices only */
+ if (strcmp(pdev->name, "fsl-cpm-fec"))
+ return;
+ mpc866ads_fixup_enet_pdata(pdev, fsid_fec1 + pdev->id - 1);
+}
+
+static void mpc866ads_fixup_scc_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for SCC devices only */
+ if (strcmp(pdev->name, "fsl-cpm-scc"))
+ return;
+
+ mpc866ads_fixup_enet_pdata(pdev, fsid_scc1 + pdev->id - 1);
+}
+
+static int mpc866ads_platform_notify(struct device *dev)
+{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {
+ "fsl-cpm-fec", mpc866ads_fixup_fec_enet_pdata}, {
+ "fsl-cpm-scc", mpc866ads_fixup_scc_enet_pdata},};
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+ dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}
+
+int __init mpc866ads_init(void)
+{
+ printk(KERN_NOTICE "mpc866ads: Init\n");
+
+ mpc866_nonplatform_device_init();
+ platform_notify = mpc866ads_platform_notify;
+
+ identify_ppc_sys_by_name(BOARD_CHIP_NAME);
+
+ ppc_sys_device_remove(MPC8xx_CPM_FEC2);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC3);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC2);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC4);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC1);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC2);
+
+ return 0;
+}
+
+arch_initcall(mpc866ads_init);
diff --git a/arch/ppc/platforms/mpc885ads_setup.c b/arch/ppc/platforms/mpc885ads_setup.c
new file mode 100644
index 0000000..37c5c7b
--- /dev/null
+++ b/arch/ppc/platforms/mpc885ads_setup.c
@@ -0,0 +1,408 @@
+/*arch/ppc/platforms/mpc885ads-setup.c
+ *
+ * Platform setup for the Freescale mpc885ads board
+ *
+ * Vitaly Bordug <vbordug@ru.mvista.com>
+ *
+ * Copyright 2005 MontaVista Software Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/param.h>
+#include <linux/string.h>
+#include <linux/ioport.h>
+#include <linux/device.h>
+
+#include <linux/fs_enet_pd.h>
+#include <linux/mii.h>
+
+#include <asm/delay.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/page.h>
+#include <asm/processor.h>
+#include <asm/system.h>
+#include <asm/time.h>
+#include <asm/ppcboot.h>
+#include <asm/8xx_immap.h>
+#include <asm/commproc.h>
+#include <asm/ppc_sys.h>
+
+extern unsigned char __res[];
+
+/* access ports */
+#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) | (_v))
+#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~(_v))
+
+#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) | (_v))
+#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~(_v))
+
+void __init mpc885ads_scc_phy_init(char);
+
+static struct fs_mii_bus_info fec_mii_bus_info = {
+ .method = fsmii_fec,
+ .id = 0,
+};
+
+static struct fs_mii_bus_info scc_mii_bus_info = {
+#ifdef CONFIG_SCC_ENET_8xx_FIXED
+ .method = fsmii_fixed,
+#else
+ .method = fsmii_fec,
+#endif
+
+ .id = 0,
+};
+
+static struct fs_platform_info mpc8xx_fec_pdata[] = {
+ {
+ .rx_ring = 128,
+ .tx_ring = 16,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 0,
+ .phy_irq = SIU_IRQ7,
+
+ .bus_info = &fec_mii_bus_info,
+ }, {
+ .rx_ring = 128,
+ .tx_ring = 16,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 1,
+ .phy_irq = SIU_IRQ7,
+
+ .bus_info = &fec_mii_bus_info,
+ }
+};
+
+static struct fs_platform_info mpc8xx_scc_pdata = {
+ .rx_ring = 64,
+ .tx_ring = 8,
+ .rx_copybreak = 240,
+
+ .use_napi = 1,
+ .napi_weight = 17,
+
+ .phy_addr = 2,
+#ifdef CONFIG_MPC8xx_SCC_ENET_FIXED
+ .phy_irq = -1,
+#else
+ .phy_irq = SIU_IRQ7,
+#endif
+
+ .bus_info = &scc_mii_bus_info,
+};
+
+static void mpc885_nonplatform_device_init(void)
+{
+ volatile cpm8xx_t *cp = cpmp;
+ unsigned *bcsr_io;
+
+#ifdef CONFIG_FS_ENET
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+#endif
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR\n");
+ return;
+ }
+#ifdef CONFIG_SERIAL_CPM_SMC1
+ cp->cp_simode &= ~(0xe0000000 >> 17); /* brg1 */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~BCSR1_RS232EN_1);
+#else
+ out_be32(bcsr_io, in_be32(bcsr_io) | BCSR1_RS232EN_1);
+ cp->cp_smc[0].smc_smcmr = 0;
+ cp->cp_smc[0].smc_smce = 0;
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SMC2
+ cp->cp_simode &= ~(0xe0000000 >> 1);
+ cp->cp_simode |= (0x20000000 >> 1); /* brg2 */
+ out_be32(bcsr_io, in_be32(bcsr_io) & ~BCSR1_RS232EN_2);
+#else
+ out_be32(bcsr_io, in_be32(bcsr_io) | BCSR1_RS232EN_2);
+ cp->cp_smc[1].smc_smcmr = 0;
+ cp->cp_smc[1].smc_smce = 0;
+#endif
+ iounmap(bcsr_io);
+
+#ifdef CONFIG_FS_ENET
+ /* use MDC for MII (common) */
+ setbits16(immap->im_ioport.iop_pdpar, 0x0080);
+ clrbits16(immap->im_ioport.iop_pddir, 0x0080);
+#endif
+}
+
+static void setup_fec1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+
+ /* configure FEC1 pins */
+ setbits16(immap->im_ioport.iop_papar, 0xf830);
+ setbits16(immap->im_ioport.iop_padir, 0x0830);
+ clrbits16(immap->im_ioport.iop_padir, 0xf000);
+ setbits32(immap->im_cpm.cp_pbpar, 0x00001001);
+
+ clrbits32(immap->im_cpm.cp_pbdir, 0x00001001);
+ setbits16(immap->im_ioport.iop_pcpar, 0x000c);
+ clrbits16(immap->im_ioport.iop_pcdir, 0x000c);
+ setbits32(immap->im_cpm.cp_pepar, 0x00000003);
+
+ setbits32(immap->im_cpm.cp_pedir, 0x00000003);
+ clrbits32(immap->im_cpm.cp_peso, 0x00000003);
+ clrbits32(immap->im_cpm.cp_cptr, 0x00000100);
+}
+
+static void setup_fec2_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+
+ /* configure FEC2 pins */
+ setbits32(immap->im_cpm.cp_pepar, 0x0003fffc);
+ setbits32(immap->im_cpm.cp_pedir, 0x0003fffc);
+ setbits32(immap->im_cpm.cp_peso, 0x00037800);
+ clrbits32(immap->im_cpm.cp_peso, 0x000087fc);
+ clrbits32(immap->im_cpm.cp_cptr, 0x00000080);
+}
+
+static void setup_scc3_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR_ADDR, BCSR_SIZE);
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR\n");
+ return;
+ }
+
+ /* Enable the PHY.
+ */
+ out_be32(bcsr_io + 4, in_be32(bcsr_io + 4) | BCSR4_ETH10_RST);
+
+ /* Configure port A pins for Txd and Rxd.
+ */
+ setbits16(immap->im_ioport.iop_papar, PA_ENET_RXD | PA_ENET_TXD);
+ clrbits16(immap->im_ioport.iop_padir, PA_ENET_RXD | PA_ENET_TXD);
+
+ /* Configure port C pins to enable CLSN and RENA.
+ */
+ clrbits16(immap->im_ioport.iop_pcpar, PC_ENET_CLSN | PC_ENET_RENA);
+ clrbits16(immap->im_ioport.iop_pcdir, PC_ENET_CLSN | PC_ENET_RENA);
+ setbits16(immap->im_ioport.iop_pcso, PC_ENET_CLSN | PC_ENET_RENA);
+
+ /* Configure port E for TCLK and RCLK.
+ */
+ setbits32(immap->im_cpm.cp_pepar, PE_ENET_TCLK | PE_ENET_RCLK);
+ clrbits32(immap->im_cpm.cp_pepar, PE_ENET_TENA);
+ clrbits32(immap->im_cpm.cp_pedir,
+ PE_ENET_TCLK | PE_ENET_RCLK | PE_ENET_TENA);
+ clrbits32(immap->im_cpm.cp_peso, PE_ENET_TCLK | PE_ENET_RCLK);
+ setbits32(immap->im_cpm.cp_peso, PE_ENET_TENA);
+
+ /* Configure Serial Interface clock routing.
+ * First, clear all SCC bits to zero, then set the ones we want.
+ */
+ clrbits32(immap->im_cpm.cp_sicr, SICR_ENET_MASK);
+ setbits32(immap->im_cpm.cp_sicr, SICR_ENET_CLKRT);
+
+ /* Disable Rx and Tx. SMC1 sshould be stopped if SCC3 eternet are used.
+ */
+ immap->im_cpm.cp_smc[0].smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
+ /* On the MPC885ADS SCC ethernet PHY is initialized in the full duplex mode
+ * by H/W setting after reset. SCC ethernet controller support only half duplex.
+ * This discrepancy of modes causes a lot of carrier lost errors.
+ */
+
+ /* In the original SCC enet driver the following code is placed at the end of the
initialization */
+ setbits32(immap->im_cpm.cp_pepar, PE_ENET_TENA);
+ clrbits32(immap->im_cpm.cp_pedir, PE_ENET_TENA);
+ setbits32(immap->im_cpm.cp_peso, PE_ENET_TENA);
+
+ out_be32(bcsr_io + 1, in_be32(bcsr_io + 1) | BCSR1_ETHEN);
+ iounmap(bcsr_io);
+}
+
+static void mpc885ads_fixup_enet_pdata(struct platform_device *pdev,
+ int fs_no)
+{
+ struct fs_platform_info *fpi = pdev->dev.platform_data;
+
+ volatile cpm8xx_t *cp;
+ bd_t *bd = (bd_t *) __res;
+ char *e;
+ int i;
+
+ /* Get pointer to Communication Processor */
+ cp = cpmp;
+ switch (fs_no) {
+ case fsid_fec1:
+ fpi = &mpc8xx_fec_pdata[0];
+ fpi->init_ioports = &setup_fec1_ioports;
+ break;
+ case fsid_fec2:
+ fpi = &mpc8xx_fec_pdata[1];
+ fpi->init_ioports = &setup_fec2_ioports;
+ break;
+ case fsid_scc3:
+ fpi = &mpc8xx_scc_pdata;
+ fpi->init_ioports = &setup_scc3_ioports;
+ mpc885ads_scc_phy_init(fpi->phy_addr);
+ break;
+ default:
+ break;
+ }
+
+ pdev->dev.platform_data = fpi;
+ fpi->fs_no = fs_no;
+
+ e = (unsigned char *)&bd->bi_enetaddr;
+ for (i = 0; i < 6; i++)
+ fpi->macaddr[i] = *e++;
+
+ fpi->macaddr[5 - pdev->id]++;
+
+}
+
+static void mpc885ads_fixup_fec_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for FEC devices only */
+ if (!strstr(pdev->name, "fsl-cpm-fec"))
+ return;
+ mpc885ads_fixup_enet_pdata(pdev, fsid_fec1 + pdev->id - 1);
+}
+
+static void __init mpc885ads_fixup_scc_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for SCC devices only */
+ if (!strstr(pdev->name, "fsl-cpm-scc"))
+ return;
+
+ mpc885ads_fixup_enet_pdata(pdev, fsid_scc1 + pdev->id - 1);
+}
+
+/* SCC ethernet controller does not have MII management channel. FEC1 MII
+ * channel is used to communicate with the 10Mbit PHY.
+ */
+
+#define MII_ECNTRL_PINMUX 0x4
+#define FEC_ECNTRL_PINMUX 0x00000004
+#define FEC_RCNTRL_MII_MODE 0x00000004
+
+/* Make MII read/write commands.
+ */
+#define mk_mii_write(REG, VAL, PHY_ADDR) (0x50020000 | (((REG) & 0x1f) << 18) | \
+ ((VAL) & 0xffff) | ((PHY_ADDR) << 23))
+
+static void mpc885ads_scc_phy_init(char phy_addr)
+{
+ volatile immap_t *immap;
+ volatile fec_t *fecp;
+ bd_t *bd;
+
+ bd = (bd_t *) __res;
+ immap = (immap_t *) IMAP_ADDR; /* pointer to internal registers */
+ fecp = &(immap->im_cpm.cp_fec);
+
+ /* Enable MII pins of the FEC1
+ */
+ setbits16(immap->im_ioport.iop_pdpar,0x0080);
+ clrbits16(immap->im_ioport.iop_pddir,0x0080);
+ /* Set MII speed to 2.5 MHz
+ */
+ out_be32(&fecp->fec_mii_speed,
+ ((((bd->bi_intfreq + 4999999) / 2500000) / 2) & 0x3F) << 1);
+
+ /* Enable FEC pin MUX
+ */
+ setbits32(fecp->fec_ecntrl, MII_ECNTRL_PINMUX);
+ setbits32(fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
+
+ out_be32(&fecp->fec_mii_data, mk_mii_write(MII_BMCR, BMCR_ISOLATE, phy_addr));
+ udelay(100);
+ out_be32(&fecp->fec_mii_data,
+ mk_mii_write(MII_ADVERTISE,
+ ADVERTISE_10HALF | ADVERTISE_CSMA,phy_addr));
+ udelay(100);
+
+ /* Disable FEC MII settings
+ */
+ clrbits32(fecp->fec_ecntrl, MII_ECNTRL_PINMUX);
+ clrbits32(fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
+ out_be32(&fecp->fec_mii_speed, 0);
+}
+
+static int mpc885ads_platform_notify(struct device *dev)
+{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {
+ "fsl-cpm-fec", mpc885ads_fixup_fec_enet_pdata}, {
+ "fsl-cpm-scc", mpc885ads_fixup_scc_enet_pdata},};
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+ dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}
+
+int __init mpc885ads_init(void)
+{
+ printk(KERN_NOTICE "mpc885ads: Init\n");
+
+ mpc885_nonplatform_device_init();
+ platform_notify = mpc885ads_platform_notify;
+
+ identify_ppc_sys_by_name(BOARD_CHIP_NAME);
+
+#ifdef CONFIG_MPC8xx_SECOND_ETH_SCC3
+ ppc_sys_device_remove(MPC8xx_CPM_FEC2);
+#endif
+#ifdef CONFIG_MPC8xx_SECOND_ETH_FEC2
+ ppc_sys_device_remove(MPC8xx_CPM_SCC3);
+#endif
+
+ ppc_sys_device_remove(MPC8xx_CPM_SCC1);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC2);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC4);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC1);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC2);
+
+ return 0;
+}
+
+arch_initcall(mpc885ads_init);
---
Sincerely,
Vitaly
^ permalink raw reply related
* Re: [PATCH] m8xx_wdt: software watchdog reset/interrupt select
From: Florian Schirmer @ 2005-11-16 11:47 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: obi, carjay, linux-ppc-embedded
In-Reply-To: <20051115142147.GD32373@logos.cnet>
Hi,
>> The SYPCR register can be set only _once_ at machine startup and the
>> bootloader in question does not have an option to change the mode. Many
>> bootloaders probably dont.
Okay, i was asuming you have control over the bootloader.
> Updated patch addresses code duplication issue you mentioned and also
> adds an error message in case timer interrupt frequency is higher
> than the watchdog frequency.
>
> Can I add your Signed-off-by in case you're OK with it?
Maybe i'm missing something obvious, but why is the interrupt driven
reaming code not working for your configuration. Are you using the PIT
for something else?
Otherwise i'm fine with the patch. Feel free to add my Signed-off-by line.
Best,
Florian
^ permalink raw reply
* Denx linux 2.4.25 on RPXLITE
From: Alexey Dyatchkov @ 2005-11-16 11:14 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: 'Ami Levi'
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Hi,
I'm trying to bring up Denx linux-2.4.25, latest found on
ftp.denx.de/pub/linux, on our proprietary board.
Our board is very much similar to RPXLITE. In fact it is RPXLITE with few
minor changes.
We did such works before, and all we usualy needed was to tune the io
mapping.
I did so with this kernel and it stucks in calibrate_delay() on "while
(ticks==jiffies)", row 207.
And it seems that no interrupts are coming to kernel (breakpoint in do_irq
is never achieved).
(No printk's on console, btw)
I'm not experienced enough in kernel debugging and feel stuck.
Please help!
Thanks in advance,
Alexey
[-- Attachment #2: Type: text/html, Size: 4276 bytes --]
^ permalink raw reply
* Test
From: Alan Carvalho @ 2005-11-16 11:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 29 bytes --]
Just a test, ignore
Alan
[-- Attachment #2: Type: text/html, Size: 41 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: David Woodhouse @ 2005-11-16 10:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <17274.63508.501761.748278@cargo.ozlabs.ibm.com>
On Wed, 2005-11-16 at 20:12 +1100, Paul Mackerras wrote:
> Yes, it works on newworld (at least it does on my G4 powerbook). It
> should work on 32-bit CHRP with any luck, but for oldworld we'll have
> to generate a COFF file.
I'll try it on Pegasos some time tonight or tomorrow. AFAICT I'm going
to need the patch which started this thread, if I want any serial ports
on my Pegasos. The newly-created asm-powerpc/serial.h file is devoid of
serial port definitions.
Here it is again, with Tom's three criticisms addressed, deliberately
ignored, and addressed. In that order.
It no longer touches asm-ppc/serial.h, so doesn't break the legacy
zImage.
---
[PATCH] Fix 8250 probe on ppc32
There are no serial ports defined in the new asm-powerpc/serial.h, and
rightly so. The 64-bit setup code has a routine to look in the device
tree for them and register a platform_device for any we find there; this
patch steals that routine and makes it available on 32-bit machines
too...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--- linux-2.6.14/drivers/serial/Makefile~ 2005-11-07 22:17:27.000000000 -0500
+++ linux-2.6.14/drivers/serial/Makefile 2005-11-07 22:17:35.000000000 -0500
@@ -22,6 +22,7 @@ obj-$(CONFIG_SERIAL_8250_ACCENT) += 8250
obj-$(CONFIG_SERIAL_8250_BOCA) += 8250_boca.o
obj-$(CONFIG_SERIAL_8250_HUB6) += 8250_hub6.o
obj-$(CONFIG_SERIAL_8250_MCA) += 8250_mca.o
+obj-$(CONFIG_SERIAL_8250_OF) += 8250_of.o
obj-$(CONFIG_SERIAL_8250_AU1X00) += 8250_au1x00.o
obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
--- linux-2.6.13/drivers/serial/8250_of.c.sof 2005-10-20 13:19:07.000000000 +0100
+++ linux-2.6.13/drivers/serial/8250_of.c 2005-10-20 13:19:26.000000000 +0100
@@ -0,0 +1,206 @@
+/*
+ * Search OpenFirmware device tree for 8250-compatible serial ports
+ *
+ * Moved from arch/powerpc/kernel/setup_64.c:
+ *
+ * Copyright (C) 2001 PPC64, IBM Corp
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#undef DEBUG
+
+#include <linux/kernel.h>
+#include <linux/serial.h>
+#include <linux/serial_8250.h>
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <asm/serial.h>
+#include <asm/prom.h>
+
+/*
+ * This function can be used by platforms to "find" legacy serial ports.
+ * It works for "serial" nodes under an "isa" node, and will try to
+ * respect the "ibm,aix-loc" property if any. It works with up to 8
+ * ports.
+ */
+
+#define MAX_LEGACY_SERIAL_PORTS 8
+static int ports_probed = 0;
+
+static struct plat_serial8250_port serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
+static unsigned int old_serial_count;
+
+void __init generic_find_legacy_serial_ports(u64 *physport,
+ unsigned int *default_speed)
+{
+ struct device_node *np;
+ u32 *sizeprop;
+
+ struct isa_reg_property {
+ u32 space;
+ u32 address;
+ u32 size;
+ };
+
+ pr_debug(" -> generic_find_legacy_serial_port()\n");
+ ports_probed = 1;
+
+ *physport = 0;
+ if (default_speed)
+ *default_speed = 0;
+
+ np = of_find_node_by_path("/");
+ if (!np)
+ return;
+
+ /* First fill our array */
+ for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
+ struct device_node *isa, *pci;
+ struct isa_reg_property *reg;
+ unsigned long phys_size, addr_size;
+ u64 io_base;
+ u32 *rangesp;
+ u32 *interrupts, *clk, *spd;
+ char *typep;
+ int index, rlen, rentsize;
+
+ /* Ok, first check if it's under an "isa" parent */
+ isa = of_get_parent(np);
+ if (!isa || strcmp(isa->name, "isa")) {
+ pr_debug("%s: no isa parent found\n", np->full_name);
+ continue;
+ }
+
+ /* Now look for an "ibm,aix-loc" property that gives us ordering
+ * if any...
+ */
+ typep = (char *)get_property(np, "ibm,aix-loc", NULL);
+
+ /* Get the ISA port number */
+ reg = (struct isa_reg_property *)get_property(np, "reg", NULL);
+ if (reg == NULL)
+ goto next_port;
+ /* We assume the interrupt number isn't translated ... */
+ interrupts = (u32 *)get_property(np, "interrupts", NULL);
+ /* get clock freq. if present */
+ clk = (u32 *)get_property(np, "clock-frequency", NULL);
+ /* get default speed if present */
+ spd = (u32 *)get_property(np, "current-speed", NULL);
+ /* Default to locate at end of array */
+ index = old_serial_count; /* end of the array by default */
+
+ /* If we have a location index, then use it */
+ if (typep && *typep == 'S') {
+ index = simple_strtol(typep+1, NULL, 0) - 1;
+ /* if index is out of range, use end of array instead */
+ if (index >= MAX_LEGACY_SERIAL_PORTS)
+ index = old_serial_count;
+ /* if our index is still out of range, that mean that
+ * array is full, we could scan for a free slot but that
+ * make little sense to bother, just skip the port
+ */
+ if (index >= MAX_LEGACY_SERIAL_PORTS)
+ goto next_port;
+ if (index >= old_serial_count)
+ old_serial_count = index + 1;
+ /* Check if there is a port who already claimed our slot */
+ if (serial_ports[index].iobase != 0) {
+ /* if we still have some room, move it, else override */
+ if (old_serial_count < MAX_LEGACY_SERIAL_PORTS) {
+ pr_debug("Moved legacy port %d -> %d\n", index,
+ old_serial_count);
+ serial_ports[old_serial_count++] =
+ serial_ports[index];
+ } else {
+ pr_debug("Replacing legacy port %d\n", index);
+ }
+ }
+ }
+ if (index >= MAX_LEGACY_SERIAL_PORTS)
+ goto next_port;
+ if (index >= old_serial_count)
+ old_serial_count = index + 1;
+
+ /* Now fill the entry */
+ memset(&serial_ports[index], 0, sizeof(struct plat_serial8250_port));
+ serial_ports[index].uartclk = (clk && *clk) ? *clk : BASE_BAUD * 16;
+ serial_ports[index].iobase = reg->address;
+ serial_ports[index].irq = interrupts ? interrupts[0] : 0;
+ serial_ports[index].flags = ASYNC_BOOT_AUTOCONF;
+
+ pr_debug("Added legacy port, index: %d, port: %x, irq: %d, clk: %d\n",
+ index,
+ serial_ports[index].iobase,
+ serial_ports[index].irq,
+ serial_ports[index].uartclk);
+
+ /* Get phys address of IO reg for port 1 */
+ if (index != 0)
+ goto next_port;
+
+ pci = of_get_parent(isa);
+ if (!pci) {
+ pr_debug("%s: no pci parent found\n", np->full_name);
+ goto next_port;
+ }
+
+ rangesp = (u32 *)get_property(pci, "ranges", &rlen);
+ if (rangesp == NULL) {
+ of_node_put(pci);
+ goto next_port;
+ }
+ rlen /= 4;
+
+ /* we need the #size-cells of the PCI bridge node itself */
+ phys_size = 1;
+ sizeprop = (u32 *)get_property(pci, "#size-cells", NULL);
+ if (sizeprop != NULL)
+ phys_size = *sizeprop;
+ /* we need the parent #addr-cells */
+ addr_size = prom_n_addr_cells(pci);
+ rentsize = 3 + addr_size + phys_size;
+ io_base = 0;
+ for (;rlen >= rentsize; rlen -= rentsize,rangesp += rentsize) {
+ if (((rangesp[0] >> 24) & 0x3) != 1)
+ continue; /* not IO space */
+ io_base = rangesp[3];
+ if (addr_size == 2)
+ io_base = (io_base << 32) | rangesp[4];
+ }
+ if (io_base != 0) {
+ *physport = io_base + reg->address;
+ if (default_speed && spd)
+ *default_speed = *spd;
+ }
+ of_node_put(pci);
+ next_port:
+ of_node_put(isa);
+ }
+
+ pr_debug(" <- generic_find_legacy_serial_port()\n");
+}
+
+static struct platform_device serial_device = {
+ .name = "serial8250",
+ .id = PLAT8250_DEV_PLATFORM,
+ .dev = {
+ .platform_data = serial_ports,
+ },
+};
+
+static int __init serial_dev_init(void)
+{
+ u64 phys;
+ unsigned int spd;
+
+ if (!ports_probed)
+ generic_find_legacy_serial_ports(&phys, &spd);
+ return platform_device_register(&serial_device);
+}
+arch_initcall(serial_dev_init);
--- linux-2.6.13/drivers/serial/Kconfig.sof 2005-10-20 12:54:48.000000000 +0100
+++ linux-2.6.13/drivers/serial/Kconfig 2005-10-20 13:05:39.000000000 +0100
@@ -77,6 +77,11 @@ config SERIAL_8250_CS
If unsure, say N.
+config SERIAL_8250_OF
+ bool
+ default y
+ depends on PPC_OF && SERIAL_8250 && PPC_MERGE
+
config SERIAL_8250_ACPI
bool "8250/16550 device discovery via ACPI namespace"
default y if IA64
--- linux-2.6.13/arch/powerpc/kernel/setup_64.c.sof 2005-10-20 13:13:08.000000000 +0100
+++ linux-2.6.13/arch/powerpc/kernel/setup_64.c 2005-10-20 13:16:28.000000000 +0100
@@ -31,8 +31,6 @@
#include <linux/notifier.h>
#include <linux/cpu.h>
#include <linux/unistd.h>
-#include <linux/serial.h>
-#include <linux/serial_8250.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/processor.h>
@@ -52,7 +50,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
@@ -1104,187 +1101,6 @@ void __init setup_default_decr(void)
lpaca->next_jiffy_update_tb = get_tb() + tb_ticks_per_jiffy;
}
-#ifndef CONFIG_PPC_ISERIES
-/*
- * This function can be used by platforms to "find" legacy serial ports.
- * It works for "serial" nodes under an "isa" node, and will try to
- * respect the "ibm,aix-loc" property if any. It works with up to 8
- * ports.
- */
-
-#define MAX_LEGACY_SERIAL_PORTS 8
-static struct plat_serial8250_port serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
-static unsigned int old_serial_count;
-
-void __init generic_find_legacy_serial_ports(u64 *physport,
- unsigned int *default_speed)
-{
- struct device_node *np;
- u32 *sizeprop;
-
- struct isa_reg_property {
- u32 space;
- u32 address;
- u32 size;
- };
- struct pci_reg_property {
- struct pci_address addr;
- u32 size_hi;
- u32 size_lo;
- };
-
- DBG(" -> generic_find_legacy_serial_port()\n");
-
- *physport = 0;
- if (default_speed)
- *default_speed = 0;
-
- np = of_find_node_by_path("/");
- if (!np)
- return;
-
- /* First fill our array */
- for (np = NULL; (np = of_find_node_by_type(np, "serial"));) {
- struct device_node *isa, *pci;
- struct isa_reg_property *reg;
- unsigned long phys_size, addr_size, io_base;
- u32 *rangesp;
- u32 *interrupts, *clk, *spd;
- char *typep;
- int index, rlen, rentsize;
-
- /* Ok, first check if it's under an "isa" parent */
- isa = of_get_parent(np);
- if (!isa || strcmp(isa->name, "isa")) {
- DBG("%s: no isa parent found\n", np->full_name);
- continue;
- }
-
- /* Now look for an "ibm,aix-loc" property that gives us ordering
- * if any...
- */
- typep = (char *)get_property(np, "ibm,aix-loc", NULL);
-
- /* Get the ISA port number */
- reg = (struct isa_reg_property *)get_property(np, "reg", NULL);
- if (reg == NULL)
- goto next_port;
- /* We assume the interrupt number isn't translated ... */
- interrupts = (u32 *)get_property(np, "interrupts", NULL);
- /* get clock freq. if present */
- clk = (u32 *)get_property(np, "clock-frequency", NULL);
- /* get default speed if present */
- spd = (u32 *)get_property(np, "current-speed", NULL);
- /* Default to locate at end of array */
- index = old_serial_count; /* end of the array by default */
-
- /* If we have a location index, then use it */
- if (typep && *typep == 'S') {
- index = simple_strtol(typep+1, NULL, 0) - 1;
- /* if index is out of range, use end of array instead */
- if (index >= MAX_LEGACY_SERIAL_PORTS)
- index = old_serial_count;
- /* if our index is still out of range, that mean that
- * array is full, we could scan for a free slot but that
- * make little sense to bother, just skip the port
- */
- if (index >= MAX_LEGACY_SERIAL_PORTS)
- goto next_port;
- if (index >= old_serial_count)
- old_serial_count = index + 1;
- /* Check if there is a port who already claimed our slot */
- if (serial_ports[index].iobase != 0) {
- /* if we still have some room, move it, else override */
- if (old_serial_count < MAX_LEGACY_SERIAL_PORTS) {
- DBG("Moved legacy port %d -> %d\n", index,
- old_serial_count);
- serial_ports[old_serial_count++] =
- serial_ports[index];
- } else {
- DBG("Replacing legacy port %d\n", index);
- }
- }
- }
- if (index >= MAX_LEGACY_SERIAL_PORTS)
- goto next_port;
- if (index >= old_serial_count)
- old_serial_count = index + 1;
-
- /* Now fill the entry */
- memset(&serial_ports[index], 0, sizeof(struct plat_serial8250_port));
- serial_ports[index].uartclk = clk ? *clk : BASE_BAUD * 16;
- serial_ports[index].iobase = reg->address;
- serial_ports[index].irq = interrupts ? interrupts[0] : 0;
- serial_ports[index].flags = ASYNC_BOOT_AUTOCONF;
-
- DBG("Added legacy port, index: %d, port: %x, irq: %d, clk: %d\n",
- index,
- serial_ports[index].iobase,
- serial_ports[index].irq,
- serial_ports[index].uartclk);
-
- /* Get phys address of IO reg for port 1 */
- if (index != 0)
- goto next_port;
-
- pci = of_get_parent(isa);
- if (!pci) {
- DBG("%s: no pci parent found\n", np->full_name);
- goto next_port;
- }
-
- rangesp = (u32 *)get_property(pci, "ranges", &rlen);
- if (rangesp == NULL) {
- of_node_put(pci);
- goto next_port;
- }
- rlen /= 4;
-
- /* we need the #size-cells of the PCI bridge node itself */
- phys_size = 1;
- sizeprop = (u32 *)get_property(pci, "#size-cells", NULL);
- if (sizeprop != NULL)
- phys_size = *sizeprop;
- /* we need the parent #addr-cells */
- addr_size = prom_n_addr_cells(pci);
- rentsize = 3 + addr_size + phys_size;
- io_base = 0;
- for (;rlen >= rentsize; rlen -= rentsize,rangesp += rentsize) {
- if (((rangesp[0] >> 24) & 0x3) != 1)
- continue; /* not IO space */
- io_base = rangesp[3];
- if (addr_size == 2)
- io_base = (io_base << 32) | rangesp[4];
- }
- if (io_base != 0) {
- *physport = io_base + reg->address;
- if (default_speed && spd)
- *default_speed = *spd;
- }
- of_node_put(pci);
- next_port:
- of_node_put(isa);
- }
-
- DBG(" <- generic_find_legacy_serial_port()\n");
-}
-
-static struct platform_device serial_device = {
- .name = "serial8250",
- .id = PLAT8250_DEV_PLATFORM,
- .dev = {
- .platform_data = serial_ports,
- },
-};
-
-static int __init serial_dev_init(void)
-{
- return platform_device_register(&serial_device);
-}
-arch_initcall(serial_dev_init);
-
-#endif /* CONFIG_PPC_ISERIES */
-
int check_legacy_ioport(unsigned long base_port)
{
if (ppc_md.check_legacy_ioport == NULL)
--
dwmw2
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Gabriel Paubert @ 2005-11-16 9:36 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <00eecfdbd5bccc7b293d847033121eee@freescale.com>
On Tue, Nov 15, 2005 at 08:19:58PM -0600, Becky Bruce wrote:
> Ben,
>
> Yeah, I clearly shouldn't run testcases at 11pm, because I got in a
> rush and only confirmed that lmw/stmw were actually taking the
> exception. Those 2 are working beautifully. To test the others, I
> need to run on a different board which, of course, isn't bootable at
> the moment. As soon as I can get that up and running, I'll try some of
> the other cases and let you know how it goes......
>
> BTW, Based on the pile of docs I have here, I think the list of
> alignment-exception-causing events on FSL's current parts (603, 603e,
> 750, 74x, 74xx, e500) is:
The 603 is still in production? And is the upcoming 8641 exactly
the same as the 74xx series in this respect?
>
> - lmw/stmw (all procs, non-word aligned)
Do we really want to emulate these instructions?
Their purpose is to minimize code size in functions prologue and
epilogue. If you hit an alignment execption with lwm/stmw, your
stack is probably misaligned for some stupid reason or bug (back
chain pointer corrrupted because of some buffer overflow comes to
mind, and you want to know ASAP).
> - single and double precision floating point ld/st ops (non-E500, non
> data size aligned)
Hmm, you can load a double from any 4 byte aligned address AFAIR.
> - dcbz to WT or CI memory (all procs)
> - dcbz with cache disabled (all procs but 603e?)
> - misaligned little endian accesses (603e)
I understand that you mention it for completeness since we
don't care about LE mode AFAICT. But I believe that there
were some differences between 603 and 603e in this area.
However we do care about byte reversal instructions, which
probably believe like the corresponding normal instruction
(i.e., lwbrx has the same rules as lwzx, etc.)
> - lwarx/stwcx (all procs)
And ldarx/stdcx. on 64 bit, but these ones should not
be emulated. So it's easy ;-)
> - multiple/string with LE set (750, 603e, 7450, 7400)
Again LE mode is probably irrelevant.
> - eciwx/ecowx (750, 7450, 7400)
Have these instructions ever been used for something
under Linux?
> - a couple of others related to vector processing
Which ones? The Altivec load and store instructions
simply mask the low order bits AFAIR.
> If anybody knows offhand of something missing there, let me know.
Nothing, but did you check when crossing a segment (256MB) boundary.
I seem to remember that some processors performed misaligned
load/store across pages but not across segments.
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: Paul Mackerras @ 2005-11-16 9:12 UTC (permalink / raw)
To: David Woodhouse; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <1132131116.28963.75.camel@baythorne.infradead.org>
David Woodhouse writes:
> .... except that it seems to have been done already -- the code which
> just landed in arch/powerpc/boot can already load a 32-bit kernel.
Yes, it works on newworld (at least it does on my G4 powerbook). It
should work on 32-bit CHRP with any luck, but for oldworld we'll have
to generate a COFF file.
Paul.
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: David Woodhouse @ 2005-11-16 8:51 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <1131382971.27347.79.camel@baythorne.infradead.org>
On Mon, 2005-11-07 at 17:02 +0000, David Woodhouse wrote:
> Or do you just mean the trivial patch to make arch/ppc64/boot/ capable
> of loading a 32-bit kernel? That'll make sense if that code gets moved
> to arch/powerpc/boot, and I'll do so then.
.... except that it seems to have been done already -- the code which
just landed in arch/powerpc/boot can already load a 32-bit kernel.
--
dwmw2
^ permalink raw reply
* Re: powerpc.git tree now on kernel.org
From: Paul Mackerras @ 2005-11-16 8:31 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: akpm, linuxppc-dev, linuxppc64-dev
In-Reply-To: <20051116082456.GA24802@lst.de>
Christoph Hellwig writes:
> Please make sure at least all patches required to kill arch/ppc64 and
> include/asm-ppc64 go to Linus. If 2.6.15 released with the include3
> hack that would mean endless pain to people building external modules
> and the distributions trying to support that.
Yes, that is my intention. For 2.6.15, at this stage, some of the
header files might end up looking like:
#ifdef CONFIG_PPC32
#include <asm-ppc/foo.h>
#else
/* contents of asm-ppc64/foo.h */
#endif
if it looks like doing a proper merge will require too many changes.
But at least it gets the files out of include/asm-ppc64.
Paul.
^ permalink raw reply
* Re: powerpc.git tree now on kernel.org
From: Christoph Hellwig @ 2005-11-16 8:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, linuxppc64-dev
In-Reply-To: <17274.51251.591579.8751@cargo.ozlabs.ibm.com>
On Wed, Nov 16, 2005 at 04:48:35PM +1100, Paul Mackerras wrote:
> Although some of these patches may go to Linus before 2.6.15 is
> released, I won't be asking Linus to pull this tree directly, since it
> is likely to get a bit messy as patches are updated. I expect that
> Andrew Morton will pull this tree periodically and include it in his
> -mm releases.
Please make sure at least all patches required to kill arch/ppc64 and
include/asm-ppc64 go to Linus. If 2.6.15 released with the include3
hack that would mean endless pain to people building external modules
and the distributions trying to support that.
^ permalink raw reply
* Fwd: powerpc.git tree now on kernel.org
From: Kumar Gala @ 2005-11-16 6:17 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org list
In-Reply-To: <17274.51251.591579.8751@cargo.ozlabs.ibm.com>
For those that only read linuxppc-embedded (and shame on you :)
- kumar
Begin forwarded message:
> From: Paul Mackerras <paulus@samba.org>
> Date: November 15, 2005 11:48:35 PM CST
> To: linuxppc-dev@ozlabs.org, linuxppc64-dev@ozlabs.org, akpm@osdl.org
> Subject: powerpc.git tree now on kernel.org
>
> I have just created a git tree for ppc/powerpc patches that are
> candidates for 2.6.16. The tree is at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
>
> Currently, besides the patches that are in the powerpc-merge.git tree,
> there are the following patches in there:
>
> Adrian Bunk:
> PPC_PREP: remove unneeded exports
>
> Benjamin Herrenschmidt:
> powerpc: Merge align.c (#2)
>
> David Gibson:
> powerpc: Remove imalloc.h
>
> David Woodhouse:
> syscall entry/exit revamp
>
> Kumar Gala:
> powerpc: moved ipic code to arch/powerpc
>
> Michael Ellerman:
> powerpc: Merge kexec
>
> Mike Kravetz:
> Remove SPAN_OTHER_NODES config definition
>
> Although some of these patches may go to Linus before 2.6.15 is
> released, I won't be asking Linus to pull this tree directly, since it
> is likely to get a bit messy as patches are updated. I expect that
> Andrew Morton will pull this tree periodically and include it in his
> -mm releases.
>
> Paul.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Benjamin Herrenschmidt @ 2005-11-16 6:13 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <324befe15b30886e86b0110c30334c8f@embeddededge.com>
On Wed, 2005-11-16 at 00:35 -0500, Dan Malek wrote:
> On Nov 16, 2005, at 12:00 AM, Benjamin Herrenschmidt wrote:
>
> > Oh well, I suppose I'll have to dig out paulus' 601 based mac :)
>
> If we don't have any contemporary processors that need
> this solution, can we just put on aside until someone
> has hardware that requires it?
I do not want to break an existing functionality with the merged file,
though for now, I suppose the merged file will only apply to
ARCH=powerpc, I can keep the old align.c in arch/ppc/kernel until it has
been properly tested on old machines.
Ben.
^ permalink raw reply
* powerpc.git tree now on kernel.org
From: Paul Mackerras @ 2005-11-16 5:48 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev, akpm
I have just created a git tree for ppc/powerpc patches that are
candidates for 2.6.16. The tree is at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
Currently, besides the patches that are in the powerpc-merge.git tree,
there are the following patches in there:
Adrian Bunk:
PPC_PREP: remove unneeded exports
Benjamin Herrenschmidt:
powerpc: Merge align.c (#2)
David Gibson:
powerpc: Remove imalloc.h
David Woodhouse:
syscall entry/exit revamp
Kumar Gala:
powerpc: moved ipic code to arch/powerpc
Michael Ellerman:
powerpc: Merge kexec
Mike Kravetz:
Remove SPAN_OTHER_NODES config definition
Although some of these patches may go to Linus before 2.6.15 is
released, I won't be asking Linus to pull this tree directly, since it
is likely to get a bit messy as patches are updated. I expect that
Andrew Morton will pull this tree periodically and include it in his
-mm releases.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Dan Malek @ 2005-11-16 5:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <1132117236.5646.75.camel@gaston>
On Nov 16, 2005, at 12:00 AM, Benjamin Herrenschmidt wrote:
> Oh well, I suppose I'll have to dig out paulus' 601 based mac :)
If we don't have any contemporary processors that need
this solution, can we just put on aside until someone
has hardware that requires it?
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Benjamin Herrenschmidt @ 2005-11-16 5:00 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <02de724e66fe23fd23a3635c8b6f049f@embeddededge.com>
On Tue, 2005-11-15 at 23:26 -0500, Dan Malek wrote:
> On Nov 15, 2005, at 9:34 PM, Benjamin Herrenschmidt wrote:
>
> > What about lwz/stw cropssing page boundaries ? Is this handled in HW ?
>
> Yep. All of these hardware alignment support features on
> the Freescale processors are the reasons they are used
> so extensively in data communication processing (where
> unaligned data can sometimes occur). All of the load/store
> alignment issues are handled in the cache subsystem, so
> to the external world all you really see are cache line
> operations. In the event of uncached data operations, you
> get the performance penalty of two bus accesses, where
> some of the data is discarded.
Oh well, I suppose I'll have to dig out paulus' 601 based mac :)
Becky, can you send me a copy of your testcase ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Dan Malek @ 2005-11-16 4:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <1132108490.5646.67.camel@gaston>
On Nov 15, 2005, at 9:34 PM, Benjamin Herrenschmidt wrote:
> What about lwz/stw cropssing page boundaries ? Is this handled in HW ?
Yep. All of these hardware alignment support features on
the Freescale processors are the reasons they are used
so extensively in data communication processing (where
unaligned data can sometimes occur). All of the load/store
alignment issues are handled in the cache subsystem, so
to the external world all you really see are cache line
operations. In the event of uncached data operations, you
get the performance penalty of two bus accesses, where
some of the data is discarded.
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Becky Bruce @ 2005-11-16 3:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <1132108490.5646.67.camel@gaston>
On Nov 15, 2005, at 8:34 PM, Benjamin Herrenschmidt wrote:
> >
> > BTW, Based on the pile of docs I have here, I think the list of
> > alignment-exception-causing events on FSL's current parts (603, 603e,
> > 750, 74x, 74xx, e500) is:
> >
> > - lmw/stmw (all procs, non-word aligned)
> > - single and double precision floating point ld/st ops (non-E500, non
> > data size aligned)
> > - dcbz to WT or CI memory (all procs)
> > - dcbz with cache disabled (all procs but 603e?)
> > - misaligned little endian accesses (603e)
> > - lwarx/stwcx (all procs)
> > - multiple/string with LE set (750, 603e, 7450, 7400)
> > - eciwx/ecowx (750, 7450, 7400)
> > - a couple of others related to vector processing
> >
> > If anybody knows offhand of something missing there, let me know.
>
> What about lwz/stw cropssing page boundaries ? Is this handled in HW ?
>
> Ben.
Apparently so, much to my surprise - I ran the testcase with those
instructions misaligned across a page boundary last night and got no
alignment exception. I was surprised, and asked my husband about it
(he worked on the load/store units for a bunch of our parts), and he
says these guys never cause an exception for any of FSL's current parts
as far as he knows. This is supported by our documentation as well -
the only place I see these listed is on 603e, where they can cause an
exception if the page is mapped little endian.
-B
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Benjamin Herrenschmidt @ 2005-11-16 2:34 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <00eecfdbd5bccc7b293d847033121eee@freescale.com>
On Tue, 2005-11-15 at 20:19 -0600, Becky Bruce wrote:
> Ben,
>
> Yeah, I clearly shouldn't run testcases at 11pm, because I got in a
> rush and only confirmed that lmw/stmw were actually taking the
> exception. Those 2 are working beautifully. To test the others, I
> need to run on a different board which, of course, isn't bootable at
> the moment. As soon as I can get that up and running, I'll try some of
> the other cases and let you know how it goes......
>
> BTW, Based on the pile of docs I have here, I think the list of
> alignment-exception-causing events on FSL's current parts (603, 603e,
> 750, 74x, 74xx, e500) is:
>
> - lmw/stmw (all procs, non-word aligned)
> - single and double precision floating point ld/st ops (non-E500, non
> data size aligned)
> - dcbz to WT or CI memory (all procs)
> - dcbz with cache disabled (all procs but 603e?)
> - misaligned little endian accesses (603e)
> - lwarx/stwcx (all procs)
> - multiple/string with LE set (750, 603e, 7450, 7400)
> - eciwx/ecowx (750, 7450, 7400)
> - a couple of others related to vector processing
>
> If anybody knows offhand of something missing there, let me know.
What about lwz/stw cropssing page boundaries ? Is this handled in HW ?
Ben.
^ permalink raw reply
* how to use the system call in the module ?
From: zjznliang @ 2005-11-16 2:19 UTC (permalink / raw)
To: linuxppc-embedded
SGkgbGludXhwcGMtZW1iZWRkZWSjoQ0KDQoJICAgICBJbiB0aGUgZGV2aWNlIGRyaXZlciwgd2Ug
YWx3YXlzIHdhbnQgdG8gc2VuZCBzb21lIGRhdGEgdG8gdGhlIGFwcGxpY2F0aW9uIC4gU28gSSB3
YXMgIHRoaW5raW5nICwgdGhlIElQQyB3b3VsZCAgZG8gbWUgYSBmYXZvciAuIEkgdXNlZCB0aGUg
c3lzX21zZ2dldCBhbmQgc3lzX21zZ3NuZCBpbiB0aGUgbW9kdWxlICxidXQgSSBnb3QgdGhpcyB3
aGVuIEkgdHlwZSB0aGUgImluc21vZCAgbW9kdWxlIiBjb21tYW5kIDoNCgkJaW5zbW9kOiB1bnJl
c29sdmVkIHN5bWJvbCBzeXNfbXNnZ2V0IA0KCQlpbnNtb2Q6IHVucmVzb2x2ZWQgc3ltYm9sIHN5
c19tc2dzbmQgDQoNCgkJSW4gbXkgb3BpbmlvbiAsdGhlIHN5c3RlbSBjYWxsIGlzIHRoZSBzeXN0
ZW0gY2FsbCB0byB0aGUgdXNlciBhcHBsaWNhdGlvbiBhbmQgdGhlIGZ1bmN0aW9uIHRvIHRoZSBr
ZXJuZWwgbW9kZSAoZWc6IG1vZHVsZSApLHNvIGhvdyB0byB1c2UgdGhlIHN5c3RlbSBjYWxsIGlu
IGtlcm5lbCBtb2RlIGlzIHRoZSB3YXkgdGhhdCBob3cgdG8gcmVjb2duaXNlIHRoZSBmdW5jdGlv
biBvZiBzeXN0ZW0gY2FsbCBpbiB0aGUgbW9kdWxlIC4NCiANCgkJQXQgdGhlIGJlZ2lubmluZywg
SSBoYWQgdG8gb3BlbiBhbmQgcmVhZCBhIGZpbGUgaW4gdGhlIG1vZHVsZSAsIHNvIEkgdXNlZCAg
dGhpcyB3YXkgdG8gYWRkIHRoZSBzeXN0ZW0gY2FsbCA6DQoNCgkJI2RlZmluZSBfS0VSTkVMX1NZ
U0NBTExTXw0KCQkjaW5jbHVkZSA8bGludXgvdW5pc3RkLmg+DQoNCgkJV2hlbiBJIHR5cGVkIHRo
ZSAiaW5zbW9kIG1vZHVsZSAiLHRoZSBzeW1ib2wgb3BlbiBhbmQgcmVhZCBjb3VsZCBiZSBmb3Vu
ZCAsYnV0IHRoZSBmdW5jdGlvbiB3YXMgbm90IGF2YWlsYWJpbGl0eS5TbyBJIGNoZWNrZWQgdGhl
IC9wcm9jL2tzeW1zIGZvciB0aGUgZnVuY3Rpb24gd2hpY2ggdGhlIGtlcm5lbCBjb3VsZCBjYWxs
ICwgYW5kIHVzZWQgdGhlIGZpbHBfb3BlbiAoKSBhbmQga2VybmVsX3JlYWQgKCkgZm9yIGluc3Rl
YWQgLg0KCQkNCgkJTm93ICwgSSBkaWQgYSB0ZXN0ICwgY29tcGlsZSB0aGUgbW9kdWxlIHdpdGgg
dGhlIGxpbnV4IGtlcm5lbCwgdGhlIHN5c19tc2dnZXQgYW5kIHN5c19tc2dzbmQgY291bGQgd29y
ayBmaW5lIC4gSSB0aG91Z2h0IHRoZSByZWFzb24gaXMgdGhhdCB0aGUgc3lzX21zZ2dldCBpcyBh
biBleHRlcm4gZnVuY3Rpb24gd2hlbiBjb21waWxpbmcgd2l0aCB0aGUga2VybmVsLlNvIHBlcmhh
cHMgLCB3aGVuIEkgZG8gaW5zbW9kIHRoZSBtb2R1bGUsIEkgZGlkIG5vdCBleHBvcnRlIHRoZSBz
eXNfbXNnZ2V0IGFuZCBzeXNfbXNnc25kIGFzIHRoZSBrZXJuZWwgc3ltYm9scy4NCg0KCQlIb3cg
dG8gZXhwb3J0ZSB0aGUgc3lzdGVtIGNhbGwgYXMgdGhlIGtlcm5lbCBzeW1ib2xzPz8gDQoNCiAg
ICAgICBBbnkgaGVscCBvbiB0aGlzIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIFRoYW5r
cyBmb3IgeW91ciBwYXRpZW5jZS4gDQoNCiAJCQkJDQoNCqGhoaF6anpubGlhbmcNCqGhoaGhoaGh
emp6bmxpYW5nX3BvcG9AMTYzLmNvbQ0KoaGhoaGhoaGhoaGhMjAwNS0xMS0xNg0K
^ 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