* Problem getting code from git repository
From: Marty @ GMail @ 2006-01-23 20:56 UTC (permalink / raw)
To: linuxppc-embedded
V2hlbiBJIGF0dGVtcHQgdG8gcmV0cmlldmUgdGhlIGN1cnJlbnQgc291cmNlIGZyb20gdGhlIGdp
dCByZXBvc2l0b3J5CkkgZ2V0IHRoZSBmb2xsb3dpbmcKCkFueSBzdWdnZXN0aW9ucyA/Pz8gIE1h
cnRpbgoKCgp3ZWRlcG9obEB1YnVudHU6L29wdC9lbGRrL3BwY182eHgvdXNyL3NyYyQgY2ctY2xv
bmUKaHR0cDovL3d3dy5kZW54LmRlL2dpdC9saW51eC0yLjYtZGVueC5naXQgbGludXgtMi42LWRl
bnguZ2l0LwpkZWZhdWx0aW5nIHRvIGxvY2FsIHN0b3JhZ2UgYXJlYQoxMzoyMzo1NSBVUkw6aHR0
cDovL3d3dy5kZW54LmRlL2dpdC9saW51eC0yLjYtZGVueC5naXQvcmVmcy9oZWFkcy9tYXN0ZXIK
WzQxLzQxXSAtPiAicmVmcy9oZWFkcy9vcmlnaW4iIFsxXQplcnJvcjogRmlsZSAxYzA2Y2Y1YTk4
NTFhODM0OTNmNWI1ZjM3NDliNGNlZDRlMDdhZjI5CihodHRwOi8vd3d3LmRlbnguZGUvZ2l0L2xp
bnV4LTIuNi1kZW54LmdpdC9vYmplY3RzLzFjLzA2Y2Y1YTk4NTFhODM0OTNmNWI1ZjM3NDliNGNl
ZDRlMDdhZjI5KQpjb3JydXB0CgpDYW5ub3Qgb2J0YWluIG5lZWRlZCBjb21taXQgMWMwNmNmNWE5
ODUxYTgzNDkzZjViNWYzNzQ5YjRjZWQ0ZTA3YWYyOQp3aGlsZSBwcm9jZXNzaW5nIGNvbW1pdCAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLgplcnJvcjogY2Fubm90IG1h
cCBzaGExIGZpbGUgMWMwNmNmNWE5ODUxYTgzNDkzZjViNWYzNzQ5YjRjZWQ0ZTA3YWYyOQpjZy1w
dWxsOiBvYmplY3RzIHB1bGwgZmFpbGVkCmNnLWluaXQ6IHB1bGwgZmFpbGVkCndlZGVwb2hsQHVi
dW50dTovb3B0L2VsZGsvcHBjXzZ4eC91c3Ivc3JjJAo=
^ permalink raw reply
* Re: [PATCH 4/9] Migrate ML300 reference design to the platform bus
From: Grant Likely @ 2006-01-23 21:13 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <43D5130E.2020404@ru.mvista.com>
Andrei Konovalov wrote:
> Hi Grant,
>
> Grant C. Likely wrote:
>
>> Signed-off-by: Grant C. Likely <grant.likely@secretlab.ca>
>>
>> ---
>>
>> arch/ppc/Kconfig.debug | 2 -
>> arch/ppc/platforms/4xx/xilinx_ml300.c | 74
>> +++++++++++++++++++++++----------
>> arch/ppc/platforms/4xx/xilinx_ml300.h | 2 -
>> arch/ppc/syslib/Makefile | 2 -
>> 4 files changed, 55 insertions(+), 25 deletions(-)
>
>
> <snip>
>
>> +/* Board specifications structures */
>> +struct ppc_sys_spec *cur_ppc_sys_spec;
>> +struct ppc_sys_spec ppc_sys_specs[] = {
>> + {
>> + /* Only one entry, always assume the same design */
>> + .ppc_sys_name = "Xilinx ML300 Reference Design",
>> + .mask = 0x00000000,
>> + .value = 0x00000000,
>
>
> "Always assume the same design" could be a considerable limitation
> for the Virtex FPGAs.
>
> <snip>
>
>> @@ -131,6 +159,8 @@ platform_init(unsigned long r3, unsigned
>> {
>> ppc4xx_init(r3, r4, r5, r6, r7);
>>
>> + identify_ppc_sys_by_id(mfspr(SPRN_PVR));
>
>
> This is OK for the single ppc_sys_specs[] case, but in general
> I am not sure using PVR to identify the system makes much sense
> in case of Virtex FPGAs. IIRC, for the mpc8xxx Freescale SOCs PVR
> gives enough information to determine what on-chip peripherals are
> present (but not how multi-function peripherals like SCC are configured).
> In case of Xilinx the situation is worse: depending on the bitstream
> loaded into the FPGA, the same chip (the same PVR) and the board
> can have several sets of on-chip peripherals which could be completely
> different from each other. And knowing the PVR value alone puts no
> limitation
> on what peripherals could get into the FPGA (unless e.g. a Virtex-4
> specific
> hardware block is used by an IP - like in case of TEMAC).
>
> What do you think?
In short; I agree 100%. There are also some other issues with the way I
set things up. The only reason I used the ppc_sys functions was because
the other freescale ports used them. (It seemed like a good starting
point). I now thing platform devices should be registered directly by
the board setup code (or flattened-device-tree parser); just like your
code below.
> So far I've used a fairly dumb code like:
>
> static int __init xilinx_platform_init(void)
> {
> #ifdef XPAR_EMAC_0_BASEADDR
> memcpy(xemac_0_pdata.mac_addr, __res.bi_enetaddr, 6);
> platform_device_register(&xilinx_emac_0_device);
> #endif /* XPAR_EMAC_0_BASEADDR */
>
> #ifdef XPAR_TEMAC_0_BASEADDR
> memcpy(xtemac_0_pdata.mac_addr, __res.bi_enetaddr, 6);
> platform_device_register(&xilinx_temac_0_device);
> #endif /* XPAR_TEMAC_0_BASEADDR */
>
> #ifdef XPAR_TFT_0_BASEADDR
> platform_device_register(&xilinx_lcd_0_device);
> #endif /* XPAR_TFT_0_BASEADDR */
>
> #ifdef XPAR_GPIO_0_BASEADDR
> platform_device_register(&xilinx_gpio_0_device);
> #endif /* XPAR_GPIO_0_BASEADDR */
> #ifdef XPAR_GPIO_1_BASEADDR
> platform_device_register(&xilinx_gpio_1_device);
> #endif /* XPAR_GPIO_1_BASEADDR */
>
> #ifdef XPAR_PS2_0_BASEADDR
> platform_device_register(&xilinx_ps2_0_device);
> #endif /* XPAR_PS2_0_BASEADDR */
> #ifdef XPAR_PS2_1_BASEADDR
> platform_device_register(&xilinx_ps2_1_device);
> #endif /* XPAR_PS2_1_BASEADDR */
>
> return 0;
> }
>
> - to associate the devices to the drivers (the drivers
> call driver_register() from their module_init function).
> This helps me holding all that ugly stuff in one file
> (this single file can be used by multiple boards),
> and should make it easier to switch to something using
> the flattened device tree parsing when the OF DT comes
> into play.
yes; plus the flattened tree parser can allocate platform device
structures as needed at runtime.
>
> Probably using ppc_sys infrastructure now has some advantages,
> but they are not evident to me.
No, I don't really think it fits for the Virtex either; I'm just using
it as a starting point.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Re: [PATCH 001/001 Updated] PMAC HD runtime blinking control
From: Cedric Pradalier @ 2006-01-23 21:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev
In-Reply-To: <1138024037.4907.24.camel@localhost.localdomain>
According to Benjamin Herrenschmidt, on Tue, 24 Jan 2006
00:47:16 +1100,
>> The key I could not understand was that hwif->gendev is
>> only initialised in the probe. So I had to move the
>> device creation after that.
>>
>> Currently, it is blinking by default. Should it be that
>> way? I guess so, since it is activated by a kernel config
>> option. It is easy to change if required.
>
>Yes. In fact, by enabled default for ATA disks and by disabled for ATAPI
>would make sense...
How do I tell the difference?. There is a 'kind' in pmif,
and also a atapi_dma flag in hwif. Which is more sensible?
>
>Also, we should think a bit about the file name... "blinking_led" isn't
>terrific for something that will end up in a non-ppc specific location.
>Or maybe on the contrary it's good ... what about "activity_led"
>rather ?
>
I'm open to any suggestion. I'll wait a bit to see if
someone else has a comment, then I'll change to
"activity_led".
--
Cedric
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-23 22:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1137883724.12998.74.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Sun, 22 Jan 2006 09:48:44 +1100
>
> On Sat, 2006-01-21 at 02:59 +0100, Gerhard Pircher wrote:
>
> > Yes, I see. :( The code mostly allocates the resources for the AGPGART
> > driver beyond the real memory space, thus preventing the X server to
> > work. Sometimes the resource is also mapped to where the resource of
> > the graphic card resides (address 0x88000000, compare with the included
> > iomem file).
>
> The AGP aperture should generally be located "outside" of those spaces.
> That is above RAM and in some place where no device already resides...
> It can be made to overlap RAM but that isn't a good idea (that's what
> happens on Macs though due to a bug in the Apple chipset).
Ahh, so the AGP aperture should not be within the memory space and any other
PCI/IO address range. Slowly but surely I become confused. ;-)
> I don't see anything related to AGP in your output... you didn't post
> the lspci as root thus it's missing all the useful infos ;)
I included a new lspci output log. :-) (now done as root)
> Also, the AGP base isn't generally a PCI BAR of the bridge... it is one
> in your case ?
I'm afraid I can't answer this question (you know, we have no datasheet for
the ArticiaS yet). From what I can see in the log, there is an unassigned
memory region (type 0, should be <4GB I guess). Could this affect AGP
operation?
Gerhard
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-23 22:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 209 bytes --]
Forgot to include the lspci log. So here it comes. Sorry!
Gerhard
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: lspci.log --]
[-- Type: text/x-log; name="lspci.log", Size: 10385 bytes --]
0000:00:00.0 Host bridge: Mai Logic Incorporated Articia S Host Bridge (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 0
Region 0: Memory at <unassigned> (32-bit, prefetchable)
Capabilities: [40] AGP version 1.0
Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
0000:00:01.0 PCI bridge: Mai Logic Incorporated Articia S PCI Bridge (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
!!! Unknown I/O range types 21/20
Memory behind bridge: 88000000-880fffff
Prefetchable memory behind bridge: 80000000-87ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
0000:00:06.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 8 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 7
Region 0: I/O ports at fe802000 [size=128]
Region 1: Memory at 98100000 (32-bit, non-prefetchable) [size=128]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 16
Region 4: I/O ports at fe00cc00 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 31, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at fe802080 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 31, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at fe8020a0 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.4 Non-VGA unclassified device: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 11
Region 0: I/O ports at fe802100 [size=256]
Region 1: I/O ports at fe802200 [size=4]
Region 2: I/O ports at fe802204 [size=4]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:07.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 30)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 11
Region 0: I/O ports at fe802300 [size=256]
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
Subsystem: Creative Labs: Unknown device 8067
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (500ns min, 5000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at fe802400 [size=32]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:09.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a)
Subsystem: Creative Labs Gameport Joystick
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128
Region 0: I/O ports at fe802420 [size=8]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) (prog-if 00 [VGA])
Subsystem: PC Partner Limited: Unknown device 7c13
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (2000ns min)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 80000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at fe002000 [size=256]
Region 2: Memory at 88000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 88020000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=<none>
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01)
Subsystem: PC Partner Limited: Unknown device 7c12
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min), Cache Line Size: 0x08 (32 bytes)
Region 0: Memory at 88000000 (32-bit, prefetchable)
Region 1: Memory at 88010000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
80000000-efffffff : PCI host bridge
80000000-87ffffff : PCI Bus #01
80000000-87ffffff : 0000:01:00.0
80000000-87ffffff : radeonfb framebuffer
88000000-880fffff : PCI Bus #01
88000000-8800ffff : 0000:01:00.0
88000000-8800ffff : radeonfb mmio
88010000-8801ffff : 0000:01:00.1
88020000-8803ffff : 0000:01:00.0
98100000-9810007f : 0000:00:06.0
00000000-00bfffff : PCI host bridge
00000000-0000001f : dma1
00000020-00000021 : 8259 (master)
00000040-0000005f : timer
00000060-0000006f : i8042
00000080-0000008f : dma page reg
000000a0-000000a1 : 8259 (slave)
000000c0-000000df : dma2
00000170-00000177 : ide1
000001f0-000001f7 : ide0
00000278-0000027a : parport2
0000027b-0000027f : parport2
000002f8-000002ff : serial
00000376-00000376 : ide1
00000378-0000037a : parport0
000003bc-000003be : parport1
000003c0-000003df : vga+
000003e8-000003ef : serial
000003f6-000003f6 : ide0
000003f8-000003ff : serial
000004d0-000004d1 : 8259 edge control
00002000-00002fff : PCI Bus #01
00002000-000020ff : 0000:01:00.0
0000cc00-0000cc0f : 0000:00:07.1
0000cc00-0000cc07 : ide0
0000cc08-0000cc0f : ide1
00802000-0080207f : 0000:00:06.0
00802000-0080207f : 0000:00:06.0
00802080-0080209f : 0000:00:07.2
00802080-0080209f : uhci_hcd
008020a0-008020bf : 0000:00:07.3
008020a0-008020bf : uhci_hcd
00802100-008021ff : 0000:00:07.5
00802200-00802203 : 0000:00:07.5
00802204-00802207 : 0000:00:07.5
00802300-008023ff : 0000:00:07.6
00802400-0080241f : 0000:00:09.0
00802400-0080241f : EMU10K1
00802420-00802427 : 0000:00:09.1
00802420-00802427 : emu10k1-gp
^ permalink raw reply
* Re: u-boot debugging
From: Wolfgang Denk @ 2006-01-23 22:32 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200601231032.38295.david.jander@protonic.nl>
Everybody:
*please* do not continue responding to this thread!
Stop feeding the troll!
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The software required `Windows 95 or better', so I installed Linux.
^ permalink raw reply
* [PATCH] powerpc: cleaned up fsl_soc.c
From: Kumar Gala @ 2006-01-23 22:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Cleaned up fsl_soc.c based on comments from Olof Johansson. Ran through
Lindent, and split gfar_mdio init into its own function.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 9a8e139654ff5807b5b8fc3f73e9d118f22a3947
tree 04fed9acbcb1565682808ac49946898ddc18a153
parent b87359141569cb0fb0fad4ba6fed7de04ec22af9
author Kumar Gala <galak@kernel.crashing.org> Mon, 23 Jan 2006 17:04:23 -0600
committer Kumar Gala <galak@kernel.crashing.org> Mon, 23 Jan 2006 17:04:23 -0600
arch/powerpc/sysdev/fsl_soc.c | 152 +++++++++++++++++++++++++----------------
1 files changed, 94 insertions(+), 58 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 064c9de..e0887d5 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -40,7 +40,7 @@ phys_addr_t get_immrbase(void)
return immrbase;
soc = of_find_node_by_type(NULL, "soc");
- if (soc != 0) {
+ if (soc) {
unsigned int size;
void *prop = get_property(soc, "reg", &size);
immrbase = of_translate_address(soc, prop);
@@ -49,21 +49,20 @@ phys_addr_t get_immrbase(void)
return immrbase;
}
-EXPORT_SYMBOL(get_immrbase);
-static const char * gfar_tx_intr = "tx";
-static const char * gfar_rx_intr = "rx";
-static const char * gfar_err_intr = "error";
+EXPORT_SYMBOL(get_immrbase);
-static int __init gfar_of_init(void)
+static int __init gfar_mdio_of_init(void)
{
struct device_node *np;
unsigned int i;
- struct platform_device *mdio_dev, *gfar_dev;
+ struct platform_device *mdio_dev;
struct resource res;
int ret;
- for (np = NULL, i = 0; (np = of_find_compatible_node(np, "mdio", "gianfar")) != NULL; i++) {
+ for (np = NULL, i = 0;
+ (np = of_find_compatible_node(np, "mdio", "gianfar")) != NULL;
+ i++) {
int k;
struct device_node *child = NULL;
struct gianfar_mdio_data mdio_data;
@@ -73,12 +72,14 @@ static int __init gfar_of_init(void)
ret = of_address_to_resource(np, 0, &res);
if (ret)
- goto mdio_err;
+ goto err;
- mdio_dev = platform_device_register_simple("fsl-gianfar_mdio", res.start, &res, 1);
+ mdio_dev =
+ platform_device_register_simple("fsl-gianfar_mdio",
+ res.start, &res, 1);
if (IS_ERR(mdio_dev)) {
ret = PTR_ERR(mdio_dev);
- goto mdio_err;
+ goto err;
}
for (k = 0; k < 32; k++)
@@ -86,17 +87,44 @@ static int __init gfar_of_init(void)
while ((child = of_get_next_child(np, child)) != NULL) {
if (child->n_intrs) {
- u32 *id = (u32 *) get_property(child, "reg", NULL);
+ u32 *id =
+ (u32 *) get_property(child, "reg", NULL);
mdio_data.irq[*id] = child->intrs[0].line;
}
}
- ret = platform_device_add_data(mdio_dev, &mdio_data, sizeof(struct gianfar_mdio_data));
+ ret =
+ platform_device_add_data(mdio_dev, &mdio_data,
+ sizeof(struct gianfar_mdio_data));
if (ret)
- goto mdio_unreg;
+ goto unreg;
}
- for (np = NULL, i = 0; (np = of_find_compatible_node(np, "network", "gianfar")) != NULL; i++) {
+ return 0;
+
+unreg:
+ platform_device_unregister(mdio_dev);
+err:
+ return ret;
+}
+
+arch_initcall(gfar_mdio_of_init);
+
+static const char *gfar_tx_intr = "tx";
+static const char *gfar_rx_intr = "rx";
+static const char *gfar_err_intr = "error";
+
+static int __init gfar_of_init(void)
+{
+ struct device_node *np;
+ unsigned int i;
+ struct platform_device *gfar_dev;
+ struct resource res;
+ int ret;
+
+ for (np = NULL, i = 0;
+ (np = of_find_compatible_node(np, "network", "gianfar")) != NULL;
+ i++) {
struct resource r[4];
struct device_node *phy, *mdio;
struct gianfar_platform_data gfar_data;
@@ -110,7 +138,7 @@ static int __init gfar_of_init(void)
ret = of_address_to_resource(np, 0, &r[0]);
if (ret)
- goto gfar_err;
+ goto err;
r[1].start = np->intrs[0].line;
r[1].end = np->intrs[0].line;
@@ -133,11 +161,13 @@ static int __init gfar_of_init(void)
r[3].flags = IORESOURCE_IRQ;
}
- gfar_dev = platform_device_register_simple("fsl-gianfar", i, &r[0], np->n_intrs + 1);
+ gfar_dev =
+ platform_device_register_simple("fsl-gianfar", i, &r[0],
+ np->n_intrs + 1);
if (IS_ERR(gfar_dev)) {
ret = PTR_ERR(gfar_dev);
- goto gfar_err;
+ goto err;
}
mac_addr = get_property(np, "address", NULL);
@@ -145,26 +175,26 @@ static int __init gfar_of_init(void)
if (model && !strcasecmp(model, "TSEC"))
gfar_data.device_flags =
- FSL_GIANFAR_DEV_HAS_GIGABIT |
- FSL_GIANFAR_DEV_HAS_COALESCE |
- FSL_GIANFAR_DEV_HAS_RMON |
- FSL_GIANFAR_DEV_HAS_MULTI_INTR;
+ FSL_GIANFAR_DEV_HAS_GIGABIT |
+ FSL_GIANFAR_DEV_HAS_COALESCE |
+ FSL_GIANFAR_DEV_HAS_RMON |
+ FSL_GIANFAR_DEV_HAS_MULTI_INTR;
if (model && !strcasecmp(model, "eTSEC"))
gfar_data.device_flags =
- FSL_GIANFAR_DEV_HAS_GIGABIT |
- FSL_GIANFAR_DEV_HAS_COALESCE |
- FSL_GIANFAR_DEV_HAS_RMON |
- FSL_GIANFAR_DEV_HAS_MULTI_INTR |
- FSL_GIANFAR_DEV_HAS_CSUM |
- FSL_GIANFAR_DEV_HAS_VLAN |
- FSL_GIANFAR_DEV_HAS_EXTENDED_HASH;
+ FSL_GIANFAR_DEV_HAS_GIGABIT |
+ FSL_GIANFAR_DEV_HAS_COALESCE |
+ FSL_GIANFAR_DEV_HAS_RMON |
+ FSL_GIANFAR_DEV_HAS_MULTI_INTR |
+ FSL_GIANFAR_DEV_HAS_CSUM |
+ FSL_GIANFAR_DEV_HAS_VLAN |
+ FSL_GIANFAR_DEV_HAS_EXTENDED_HASH;
ph = (phandle *) get_property(np, "phy-handle", NULL);
phy = of_find_node_by_phandle(*ph);
if (phy == NULL) {
ret = -ENODEV;
- goto gfar_unreg;
+ goto unreg;
}
mdio = of_get_parent(phy);
@@ -174,7 +204,7 @@ static int __init gfar_of_init(void)
if (ret) {
of_node_put(phy);
of_node_put(mdio);
- goto gfar_unreg;
+ goto unreg;
}
gfar_data.phy_id = *id;
@@ -183,23 +213,22 @@ static int __init gfar_of_init(void)
of_node_put(phy);
of_node_put(mdio);
- ret = platform_device_add_data(gfar_dev, &gfar_data, sizeof(struct gianfar_platform_data));
+ ret =
+ platform_device_add_data(gfar_dev, &gfar_data,
+ sizeof(struct
+ gianfar_platform_data));
if (ret)
- goto gfar_unreg;
+ goto unreg;
}
return 0;
-mdio_unreg:
- platform_device_unregister(mdio_dev);
-mdio_err:
- return ret;
-
-gfar_unreg:
+unreg:
platform_device_unregister(gfar_dev);
-gfar_err:
+err:
return ret;
}
+
arch_initcall(gfar_of_init);
static int __init fsl_i2c_of_init(void)
@@ -209,17 +238,19 @@ static int __init fsl_i2c_of_init(void)
struct platform_device *i2c_dev;
int ret;
- for (np = NULL, i = 0; (np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL; i++) {
+ for (np = NULL, i = 0;
+ (np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL;
+ i++) {
struct resource r[2];
struct fsl_i2c_platform_data i2c_data;
- unsigned char * flags = NULL;
+ unsigned char *flags = NULL;
memset(&r, 0, sizeof(r));
memset(&i2c_data, 0, sizeof(i2c_data));
ret = of_address_to_resource(np, 0, &r[0]);
if (ret)
- goto i2c_err;
+ goto err;
r[1].start = np->intrs[0].line;
r[1].end = np->intrs[0].line;
@@ -228,7 +259,7 @@ static int __init fsl_i2c_of_init(void)
i2c_dev = platform_device_register_simple("fsl-i2c", i, r, 2);
if (IS_ERR(i2c_dev)) {
ret = PTR_ERR(i2c_dev);
- goto i2c_err;
+ goto err;
}
i2c_data.device_flags = 0;
@@ -240,18 +271,22 @@ static int __init fsl_i2c_of_init(void)
if (flags)
i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
- ret = platform_device_add_data(i2c_dev, &i2c_data, sizeof(struct fsl_i2c_platform_data));
+ ret =
+ platform_device_add_data(i2c_dev, &i2c_data,
+ sizeof(struct
+ fsl_i2c_platform_data));
if (ret)
- goto i2c_unreg;
+ goto unreg;
}
return 0;
-i2c_unreg:
+unreg:
platform_device_unregister(i2c_dev);
-i2c_err:
+err:
return ret;
}
+
arch_initcall(fsl_i2c_of_init);
#ifdef CONFIG_PPC_83xx
@@ -267,51 +302,52 @@ static int __init mpc83xx_wdt_init(void)
if (!np) {
ret = -ENODEV;
- goto mpc83xx_wdt_nodev;
+ goto nodev;
}
soc = of_find_node_by_type(NULL, "soc");
if (!soc) {
ret = -ENODEV;
- goto mpc83xx_wdt_nosoc;
+ goto nosoc;
}
freq = (unsigned int *)get_property(soc, "bus-frequency", NULL);
if (!freq) {
ret = -ENODEV;
- goto mpc83xx_wdt_err;
+ goto err;
}
memset(&r, 0, sizeof(r));
ret = of_address_to_resource(np, 0, &r);
if (ret)
- goto mpc83xx_wdt_err;
+ goto err;
dev = platform_device_register_simple("mpc83xx_wdt", 0, &r, 1);
if (IS_ERR(dev)) {
ret = PTR_ERR(dev);
- goto mpc83xx_wdt_err;
+ goto err;
}
ret = platform_device_add_data(dev, freq, sizeof(int));
if (ret)
- goto mpc83xx_wdt_unreg;
+ goto unreg;
of_node_put(soc);
of_node_put(np);
return 0;
-mpc83xx_wdt_unreg:
+unreg:
platform_device_unregister(dev);
-mpc83xx_wdt_err:
+err:
of_node_put(soc);
-mpc83xx_wdt_nosoc:
+nosoc:
of_node_put(np);
-mpc83xx_wdt_nodev:
+nodev:
return ret;
}
+
arch_initcall(mpc83xx_wdt_init);
#endif
^ permalink raw reply related
* Re: [PATCH 001/001 Updated] PMAC HD runtime blinking control
From: Benjamin Herrenschmidt @ 2006-01-23 23:10 UTC (permalink / raw)
To: Cedric Pradalier; +Cc: Linuxppc-dev
In-Reply-To: <20060124073133.5cab0e93.cedric.pradalier@inrialpes.fr>
On Tue, 2006-01-24 at 07:31 +1000, Cedric Pradalier wrote:
> According to Benjamin Herrenschmidt, on Tue, 24 Jan 2006
> 00:47:16 +1100,
> >> The key I could not understand was that hwif->gendev is
> >> only initialised in the probe. So I had to move the
> >> device creation after that.
> >>
> >> Currently, it is blinking by default. Should it be that
> >> way? I guess so, since it is activated by a kernel config
> >> option. It is easy to change if required.
> >
> >Yes. In fact, by enabled default for ATA disks and by disabled for ATAPI
> >would make sense...
>
> How do I tell the difference?. There is a 'kind' in pmif,
> and also a atapi_dma flag in hwif. Which is more sensible?
You need to check drive->media ... Which is a bit annoying since it mans
it's per drive, not per-HWIF... you may want to move your sysfs entry
down one more level :) (Each HWIF has an array of 2 drives, though check
drive->present before expecting a useful struct device there)
> >Also, we should think a bit about the file name... "blinking_led" isn't
> >terrific for something that will end up in a non-ppc specific location.
> >Or maybe on the contrary it's good ... what about "activity_led"
> >rather ?
> >
>
> I'm open to any suggestion. I'll wait a bit to see if
> someone else has a comment, then I'll change to
> "activity_led".
>
> --
> Cedric
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Benjamin Herrenschmidt @ 2006-01-23 23:15 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <29335.1138054327@www080.gmx.net>
On Mon, 2006-01-23 at 23:12 +0100, Gerhard Pircher wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> > Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> > Datum: Sun, 22 Jan 2006 09:48:44 +1100
> >
> > On Sat, 2006-01-21 at 02:59 +0100, Gerhard Pircher wrote:
> >
> > > Yes, I see. :( The code mostly allocates the resources for the AGPGART
> > > driver beyond the real memory space, thus preventing the X server to
> > > work. Sometimes the resource is also mapped to where the resource of
> > > the graphic card resides (address 0x88000000, compare with the included
> > > iomem file).
> >
> > The AGP aperture should generally be located "outside" of those spaces.
> > That is above RAM and in some place where no device already resides...
> > It can be made to overlap RAM but that isn't a good idea (that's what
> > happens on Macs though due to a bug in the Apple chipset).
> Ahh, so the AGP aperture should not be within the memory space and any other
> PCI/IO address range. Slowly but surely I become confused. ;-)
>
> > I don't see anything related to AGP in your output... you didn't post
> > the lspci as root thus it's missing all the useful infos ;)
> I included a new lspci output log. :-) (now done as root)
>
> > Also, the AGP base isn't generally a PCI BAR of the bridge... it is one
> > in your case ?
> I'm afraid I can't answer this question (you know, we have no datasheet for
> the ArticiaS yet). From what I can see in the log, there is an unassigned
> memory region (type 0, should be <4GB I guess). Could this affect AGP
> operation?
No idea... memory BARs on host bridges can be anything... It might just
be the normal PCI DMA region.
Ben.
^ permalink raw reply
* [PATCH] Updated Patch to add support for Freescale 83xx Host Mode USB
From: Randy Vinson @ 2006-01-23 23:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
Greetings,
I've attached an updated patch (based on 2.6.16-rc1) which adds
Host mode support for the Dual-Role(DR) and Multi-Port-Host (MPH) USB
controllers found in the Freescale 8349. The update was to reconcile the
port numbering scheme such that it matches the 8349 documentation. Since
my previous patch has not yet gone upstream, the maintainer requested a
fresh patch.
Note that this patch only provides the platform-specific code that
sets up the external hardware and pin configuration. The actual DR and
MPH controller driver was posted on the linux-usb-devel mailing list.
Using a Freescale 8349CDS reference board, the DR and MPH
controllers have been successfully tested using a USB 2.0 high speed
FLASH drive, a USB 1.1 full speed 4-port hub and a Siemens SpeedStream
USB to Ethernet adapter (assuming the previous 8349 driver updates
posted to linux-usb-devel have been applied).
Randy Vinson
MontaVista Software
[-- Attachment #2: updated_8349_usb_platform.patch --]
[-- Type: text/plain, Size: 8578 bytes --]
Adding platform support for the 834x Host Mode USB controller.
This patch provides the platform-specific hardware setup required by the
83xx Host Mode USB controller on the Freescale 8349CDS reference system.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
commit 30caa62b0e433b466b0880efa32375359b6e4fea
tree e9bacf15ad1a58f6f15a343a2b5f233affec0ca1
parent a3d36ef38dcdcbbc7e1860f2f92569145524b1d5
author Randy Vinson <rvinson@linuxbox.(none)> Mon, 23 Jan 2006 16:46:39 -0700
committer Randy Vinson <rvinson@linuxbox.(none)> Mon, 23 Jan 2006 16:46:39 -0700
arch/ppc/Kconfig | 2 +
arch/ppc/platforms/83xx/Kconfig | 28 +++++++++
arch/ppc/platforms/83xx/mpc834x_sys.c | 100 +++++++++++++++++++++++++++++++++
arch/ppc/platforms/83xx/mpc834x_sys.h | 3 +
arch/ppc/syslib/mpc83xx_devices.c | 16 +++++
include/asm-ppc/mpc83xx.h | 17 ++++++
6 files changed, 166 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
index 11899f0..b33b0eb 100644
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -681,6 +681,8 @@ config EV64360
platform.
endchoice
+source arch/ppc/platforms/83xx/Kconfig
+
config PQ2ADS
bool
depends on ADS8272
diff --git a/arch/ppc/platforms/83xx/Kconfig b/arch/ppc/platforms/83xx/Kconfig
new file mode 100644
index 0000000..90bc67a
--- /dev/null
+++ b/arch/ppc/platforms/83xx/Kconfig
@@ -0,0 +1,28 @@
+config 834x_USB_SUPPORT
+ bool "834x USB Support"
+ depends on MPC834x_SYS
+ default y
+ ---help---
+ Enables support for the USB controllers on the MPC834x chip. The 834x
+ reference board is wired for only one USB port. That port may be
+ used by either the MPH or DR USB controller.
+ Requires USB Host EHCI support.
+ If unsure, say Y.
+choice
+ prompt "834x USB Controller Selection"
+ depends on 834x_USB_SUPPORT
+ default 834x_DR_USB_SUPPORT
+
+config 834x_DR_USB_SUPPORT
+ bool "DR Controller"
+ select USB_EHCI_ROOT_HUB_TT
+ ---help---
+ Select if using the Dual-Role (DR) USB controller.
+
+config 834x_MPH_USB_SUPPORT
+ bool "MPH Controller"
+ ---help---
+ Select if using the Multi-Port-Host (MPH) USB controller.
+
+endchoice
+
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c b/arch/ppc/platforms/83xx/mpc834x_sys.c
index 012e1e6..319661e 100644
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -11,6 +11,9 @@
* 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.
+ *
+ * USB setup added by Randy Vinson <rvinson@mvista.com> based on code from
+ * Hunter Wu.
*/
#include <linux/config.h>
@@ -93,6 +96,99 @@ mpc83xx_exclude_device(u_char bus, u_cha
}
#endif /* CONFIG_PCI */
+/*
+ * Configure the on-chip USB controller. The MPC834xCDS only supports the
+ * second USB interface (port 1). This code sets up the hardware and then
+ * lets the platform driver take over device setup.
+ */
+
+#ifdef CONFIG_834x_USB_SUPPORT
+void mpc834x_board_init(void)
+{
+ unsigned char __iomem *bcsr;
+ volatile unsigned char *bcsr5_p;
+
+ /*
+ * if SYS board is plug into PIB board,
+ * force to use the PHY on SYS board
+ * */
+ bcsr = ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
+ bcsr5_p = bcsr + BCSR5_OFF;
+ if ( (*bcsr5_p & BCSR5_INT_USB) == 0 )
+ *bcsr5_p = (*bcsr5_p | BCSR5_INT_USB);
+ iounmap(bcsr);
+}
+
+void mpc834x_usb_clk_cfg(void)
+{
+ unsigned long sccr;
+ volatile unsigned long *p;
+
+ p = (volatile unsigned long *)(VIRT_IMMRBAR + MPC83XX_SCCR_OFFS); /* SCCR */
+ sccr = *p;
+
+ sccr |= MPC83XX_SCCR_USB_MPHCM_11 | MPC83XX_SCCR_USB_DRCM_11;
+
+ *p = sccr;
+}
+
+static void mpc834x_usb_pin_cfg(struct fsl_usb2_platform_data *pdata)
+{
+ unsigned long sicrl;
+ volatile unsigned long *p;
+
+ p = (volatile unsigned long *)(VIRT_IMMRBAR + MPC83XX_SICRL_OFFS); /* SCCR */
+ sicrl = *p;
+
+ /* set both ports to MPH mode */
+ sicrl &= ~(MPC83XX_SICRL_USB0 | MPC83XX_SICRL_USB1);
+
+ if (pdata->operating_mode == FSL_USB2_DR_HOST) {
+ if (pdata->phy_mode == FSL_USB2_PHY_UTMI_WIDE) {
+ /* UTMI WIDE combines both ports into a single 16-bit port */
+ sicrl |= MPC83XX_SICRL_USB0 | MPC83XX_SICRL_USB1;
+ }
+ else {
+ if (pdata->port_enables & FSL_USB2_PORT1_ENABLED)
+ sicrl |= MPC83XX_SICRL_USB1;
+ }
+ }
+ *p = sicrl;
+}
+
+static void __init
+mpc834x_usb_init(void)
+{
+ struct fsl_usb2_platform_data *pdata;
+
+#ifdef CONFIG_834x_DR_USB_SUPPORT
+ ppc_sys_device_remove(MPC83xx_USB2_MPH);
+ pdata = (struct fsl_usb2_platform_data *) ppc_sys_get_pdata(MPC83xx_USB2_DR);
+
+ if (pdata) {
+ pdata->phy_mode = FSL_USB2_PHY_ULPI;
+ pdata->operating_mode = FSL_USB2_DR_HOST;
+ pdata->port_enables = FSL_USB2_PORT1_ENABLED;
+ }
+
+#elif defined(CONFIG_834x_MPH_USB_SUPPORT)
+ ppc_sys_device_remove(MPC83xx_USB2_DR);
+ pdata = (struct fsl_usb2_platform_data *) ppc_sys_get_pdata(MPC83xx_USB2_MPH);
+
+ if (pdata) {
+ pdata->phy_mode = FSL_USB2_PHY_ULPI;
+ pdata->operating_mode = FSL_USB2_MPH_HOST;
+ pdata->port_enables = FSL_USB2_PORT1_ENABLED;
+ }
+
+#endif
+ mpc834x_usb_pin_cfg(pdata);
+ mpc834x_board_init();
+ mpc834x_usb_clk_cfg();
+ return;
+}
+#endif /* CONFIG_834x_USB_SUPPORT */
+
/* ************************************************************************
*
* Setup the architecture
@@ -144,6 +240,10 @@ mpc834x_sys_setup_arch(void)
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
+#ifdef CONFIG_834x_USB_SUPPORT
+ mpc834x_usb_init();
+#endif
+
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
ROOT_DEV = Root_RAM0;
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.h b/arch/ppc/platforms/83xx/mpc834x_sys.h
index 2e514d3..fab3762 100644
--- a/arch/ppc/platforms/83xx/mpc834x_sys.h
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.h
@@ -27,6 +27,9 @@
#define BCSR_PHYS_ADDR ((uint)0xf8000000)
#define BCSR_SIZE ((uint)(128 * 1024))
+#define BCSR5_OFF 0x05
+#define BCSR5_INT_USB 0x02
+
#define BCSR_MISC_REG2_OFF 0x07
#define BCSR_MISC_REG2_PORESET 0x01
diff --git a/arch/ppc/syslib/mpc83xx_devices.c b/arch/ppc/syslib/mpc83xx_devices.c
index f9b95de..916926c 100644
--- a/arch/ppc/syslib/mpc83xx_devices.c
+++ b/arch/ppc/syslib/mpc83xx_devices.c
@@ -23,6 +23,8 @@
#include <asm/ppc_sys.h>
#include <asm/machdep.h>
+static u64 mpc83xx_dma_mask = 0xffffffffULL;
+
/* We use offsets for IORESOURCE_MEM since we do not know at compile time
* what IMMRBAR is, will get fixed up by mach_mpc83xx_fixup
*/
@@ -50,6 +52,14 @@ static struct fsl_i2c_platform_data mpc8
.device_flags = FSL_I2C_DEV_SEPARATE_DFSRR,
};
+/* Placeholder to be filled in by board code */
+static struct fsl_usb2_platform_data mpc83xx_fsl_dr_pdata = {
+};
+
+/* Placeholder to be filled in by board code */
+static struct fsl_usb2_platform_data mpc83xx_fsl_mph_pdata = {
+};
+
static struct plat_serial8250_port serial_platform_data[] = {
[0] = {
.mapbase = 0x4500,
@@ -190,7 +200,10 @@ struct platform_device ppc_sys_platform_
[MPC83xx_USB2_DR] = {
.name = "fsl-usb2-dr",
.id = 1,
+ .dev.platform_data = &mpc83xx_fsl_dr_pdata,
.num_resources = 2,
+ .dev.dma_mask = &mpc83xx_dma_mask,
+ .dev.coherent_dma_mask = 0xffffffffULL,
.resource = (struct resource[]) {
{
.start = 0x23000,
@@ -208,6 +221,9 @@ struct platform_device ppc_sys_platform_
.name = "fsl-usb2-mph",
.id = 1,
.num_resources = 2,
+ .dev.platform_data = &mpc83xx_fsl_mph_pdata,
+ .dev.dma_mask = &mpc83xx_dma_mask,
+ .dev.coherent_dma_mask = 0xffffffffULL,
.resource = (struct resource[]) {
{
.start = 0x22000,
diff --git a/include/asm-ppc/mpc83xx.h b/include/asm-ppc/mpc83xx.h
index 7cdf60f..74957a6 100644
--- a/include/asm-ppc/mpc83xx.h
+++ b/include/asm-ppc/mpc83xx.h
@@ -95,6 +95,23 @@ extern unsigned char __res[];
#define MPC83xx_CCSRBAR_SIZE (1024*1024)
+#define MPC83XX_SCCR_OFFS 0xA08
+#define MPC83XX_SCCR_USB_MPHCM_11 0x00c00000
+#define MPC83XX_SCCR_USB_MPHCM_01 0x00400000
+#define MPC83XX_SCCR_USB_MPHCM_10 0x00800000
+#define MPC83XX_SCCR_USB_DRCM_11 0x00300000
+#define MPC83XX_SCCR_USB_DRCM_01 0x00100000
+#define MPC83XX_SCCR_USB_DRCM_10 0x00200000
+
+/* system i/o configuration register low */
+#define MPC83XX_SICRL_OFFS 0x114
+#define MPC83XX_SICRL_USB1 0x40000000
+#define MPC83XX_SICRL_USB0 0x20000000
+
+/* system i/o configuration register high */
+#define MPC83XX_SICRH_OFFS 0x118
+#define MPC83XX_SICRH_USB_UTMI 0x00020000
+
/* Let modules/drivers get at immrbar (physical) */
extern phys_addr_t immrbar;
^ permalink raw reply related
* MCC Driver
From: s.maiti @ 2006-01-24 5:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.166.1137617278.17753.linuxppc-embedded@ozlabs.org>
In the MCC driver as in www.sourceforge.com there is no information of
clock routing and I/O routing. It is commented that ""clock routing and
I/O routing supposed done in fec001a_setup.c."" I am using Linux-2.4.25
and couldn't find the file.
I will be highly grateful if anyone can help me with the information that
where should I look for the corresponding file in Linux-2.4.25 so that i
can provide the information's or we have to include those information's in
the driver.
Thanks and regards,
Souvik Maiti
Tata Consultancy Services Limited
Mailto: s.maiti@tcs.com
Website: http://www.tcs.com
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
^ permalink raw reply
* Linux kernel and u-boot debugging with Eclipse IDE
From: IGOR LURI @ 2006-01-24 7:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
Hi all,
We have a MPC5200Lite board running Linux 2.4.25 and u-boot 1.1.4. We are able to debug Linux kernel and U-boot using DDD/GDB and BDI2000, and we are trying to use Eclipse IDE (with CDT plugin) / BDI2000 to develop and debug software.
Eclipse works well to remote debugging aplications over ethernet, however, we are not able to debug Linux kernel or u-boot using Eclipse. When it stops in the first breakpoint, I can´t view some variables and stepping into a function, it shows another. It seems that Eclipse has problems with Linux kernel and u-boot symbols.
Someone uses Eclipse and BDI2000 to debug Linux kernel and u-boot?
Igor Luri
R&D Software Department
Fagor Automation S. Coop.
[-- Attachment #2: Type: text/html, Size: 1404 bytes --]
^ permalink raw reply
* Trouble with SMC serial port in ppc/boot/simple on Embedded Planet 8248 board
From: Laurent Pinchart @ 2006-01-24 8:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
(First of all, this is a repost of a mail I sent yesterday for which I haven't
received a copy from the mailing list and which does not appear in the
archives. If the mail hasn't been dropped, sorry for the duplicate).
I'm trying to port the Linux kernel (2.6.15.1) to the Embedded Planet 8248
board. The board has a proprietary boot loader and uses SMC1 has a serial
console.
After some work (2.6.15.1 has a nasty bug related to relocation which has been
fixed in the git tree), I have been able to load and start the kernel image.
Unfortunately, the early serial output is lost. Here is the kernel boot
messages I get with 2.6.15.1 :
-----------------------------------------------------------------------------
Embedded Planet EP8248 PowerPC port
Built 1 zonelists
Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram0 rw
PID hash table entries: 4096 (order: 12, 65536 bytes)
Warning: real time clock seems stuck!
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 777088k available (1520k kernel code, 440k data, 96k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
-----------------------------------------------------------------------------
And here is the same with the modified 2.6.10-pre3 kernel shipped with the
board:
-----------------------------------------------------------------------------
loaded at: 00200000 002D01E8
relocated to: 00400000 004D01E8
board data at: 004CE12C 004CE168
relocated to: 0040509C 004050D8
zimage at: 00405A31 004CD2C4
avail ram: 004D1000 01000000
Linux/PPC load: console=ttyCPM0,9600n8 root=/dev/ram0 rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.10-rc3 (laurent@pclaurent) (gcc version 3.4.1) #5 Thu Jan 19
15:25:42 CET 2006
Embedded Planet EP8248 PowerPC port
Built 1 zonelists
[...]
-----------------------------------------------------------------------------
Early boot messages (printed with puts in ppc/boot/simple/misc-embedded.c) are
lost.
I compared the Embedded Planet kernel with the 2.6.10-rc3 from kernel.org,
haven't seen any big change related to the SMC serial port. Embedded Planet
uses BRGC7 instead of BRGC1 for SMC1, but that didn't work better for me.
I of course enabled the RS232 transceivers in the board control and status
registers (BCSR).
Could anyone give me any pointer to where I should look at ?
Thanks in advance,
Laurent Pinchart
^ permalink raw reply
* [PATCH 001/001 Updated again] PMAC HD runtime blinking control
From: Cedric Pradalier @ 2006-01-24 12:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev
In-Reply-To: <1138057827.4907.30.camel@localhost.localdomain>
According to Benjamin Herrenschmidt, on Tue, 24 Jan 2006
10:10:26 +1100,
>On Tue, 2006-01-24 at 07:31 +1000, Cedric Pradalier wrote:
>> >
>> >Yes. In fact, by enabled default for ATA disks and by disabled for ATAPI
>> >would make sense...
>>
>> How do I tell the difference?. There is a 'kind' in pmif,
>> and also a atapi_dma flag in hwif. Which is more sensible?
>
>You need to check drive->media ... Which is a bit annoying since it mans
>it's per drive, not per-HWIF... you may want to move your sysfs entry
>down one more level :) (Each HWIF has an array of 2 drives, though check
>drive->present before expecting a useful struct device there)
>
Well in this case, I'll let this part waiting for now.
I don't think there will be enough real users of this minor
thing to justify putting any more efforts for now.
I think the practical solution is to disable the led by
default. The few user who will want it will be able to add
either ide_core.blink to their boot parameter or make a
small init.d script to put 1 into the sysfs entry.
That's the way I've implemented it, and I've changed the
name into activity_led.
pradalier@localhost:~$ find /sys/ -name activity_led
/sys/devices/pci0001:10/0001:10:17.0/0.80000000:mac-io/0.0001f000:ata-4/ide0/activity_led
This is the updated version of the patch. I, for one, will
consider it stable now.
signed-off-by: Cedric Pradalier <cedric.pradalier@free.fr>
---
--- drivers/ide/ppc/pmac.c.orig 2006-01-03 13:21:10.000000000 +1000
+++ drivers/ide/ppc/pmac.c 2006-01-24 21:18:36.000000000 +1000
@@ -36,6 +36,11 @@
#include <linux/pmu.h>
#include <linux/scatterlist.h>
+#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+#include <linux/device.h>
+#include <asm/of_device.h>
+#endif
+
#include <asm/prom.h>
#include <asm/io.h>
#include <asm/dbdma.h>
@@ -427,6 +432,15 @@ static void pmac_ide_kauai_selectproc(id
#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+MODULE_AUTHOR("Paul Mackerras & Ben. Herrenschmidt");
+MODULE_DESCRIPTION("Support for IDE interfaces on PowerMacs");
+MODULE_LICENSE("GPL");
+
+static int activity_led = 0;
+module_param_named(blink,activity_led, bool, 0666);
+MODULE_PARM_DESC(blink,"Enable/Disable activity led [Default: disabled]");
+
+
/* Set to 50ms minimum led-on time (also used to limit frequency
* of requests sent to the PMU
*/
@@ -437,8 +451,7 @@ static spinlock_t pmu_blink_lock;
static unsigned long pmu_blink_stoptime;
static int pmu_blink_ledstate;
static struct timer_list pmu_blink_timer;
-static int pmu_ide_blink_enabled;
-
+static int pmu_ide_blink_enabled = 0;
static void
pmu_hd_blink_timeout(unsigned long data)
@@ -468,6 +481,8 @@ static void
pmu_hd_kick_blink(void *data, int rw)
{
unsigned long flags;
+ if (!activity_led)
+ return;
pmu_blink_stoptime = jiffies + PMU_HD_BLINK_TIME;
wmb();
@@ -483,6 +498,26 @@ pmu_hd_kick_blink(void *data, int rw)
spin_unlock_irqrestore(&pmu_blink_lock, flags);
}
+static ssize_t show_activity_led_enable(struct device *dev, struct device_attribute *attr, char *buf)\
+{
+ return sprintf(buf, "%c\n", activity_led?'1':'0');
+}
+
+static ssize_t set_activity_led_enable(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int blink=0;
+ if (sscanf (buf, "%d", &blink) != 1)
+ return -EINVAL;
+ activity_led = (blink != 0);
+ printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
+ activity_led?"enabled":"disabled");
+ return count;
+}
+
+static DEVICE_ATTR (activity_led, S_IRUGO | S_IWUSR,
+ show_activity_led_enable, set_activity_led_enable);
+
static int
pmu_hd_blink_init(void)
{
@@ -516,6 +551,9 @@ pmu_hd_blink_init(void)
init_timer(&pmu_blink_timer);
pmu_blink_timer.function = pmu_hd_blink_timeout;
+ printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
+ activity_led?"enabled":"disabled");
+
return 1;
}
@@ -1271,7 +1309,7 @@ static int
pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif)
{
struct device_node *np = pmif->node;
- int *bidp, i;
+ int *bidp;
pmif->cable_80 = 0;
pmif->broken_dma = pmif->broken_dma_warn = 0;
@@ -1401,6 +1439,12 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
/* We probe the hwif now */
probe_hwif_init(hwif);
+#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+ /* We wait till here to have the gendev initialized in hwif */
+ device_create_file (&hwif->gendev, &dev_attr_activity_led);
+#endif
+
+
return 0;
}
^ permalink raw reply
* [PATCH] Add support for lite5200b board.
From: John Rigby @ 2006-01-24 17:12 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 64 bytes --]
Sylvain,
Here is an updated patch for the liteb board.
John
[-- Attachment #2: liteb.patch --]
[-- Type: text/x-patch, Size: 4151 bytes --]
Adds support for liteb board.
Signed-off-by: John Rigby <jrigby@freescale.com>
arch/ppc/Kconfig | 8 ++++++++
arch/ppc/platforms/lite5200.c | 38 +++++++++++++++++++++++++++++++++++---
arch/ppc/syslib/mpc52xx_pci.c | 3 ++-
include/linux/pci_ids.h | 1 +
4 files changed, 46 insertions(+), 4 deletions(-)
3a68d4fcd6a175c7887e570b3f11af07a812bdc0
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
index 11899f0..eecb608 100644
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -664,6 +664,14 @@ config LITE5200
much but it's only been tested on this board version. I think this
board is also known as IceCube.
+config LITE5200B
+ bool "Freescale LITE5200B"
+ depends on LITE5200
+ help
+ Support for the LITE5200B dev board for the MPC5200 from Freescale.
+ This is the new board with 2 PCI slots.
+
+
config MPC834x_SYS
bool "Freescale MPC834x SYS"
help
diff --git a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
index 7ed52dc..8cd9c67 100644
--- a/arch/ppc/platforms/lite5200.c
+++ b/arch/ppc/platforms/lite5200.c
@@ -36,6 +36,7 @@
#include <asm/mpc52xx.h>
#include <asm/ppc_sys.h>
#include <asm/machdep.h>
+#include <asm/pci-bridge.h>
#include <syslib/mpc52xx_pci.h>
@@ -70,12 +71,32 @@ lite5200_show_cpuinfo(struct seq_file *m
}
#ifdef CONFIG_PCI
+#ifdef CONFIG_LITE5200B
+static int
+lite5200_map_irq(struct pci_dev *dev, unsigned char idsel,
+ unsigned char pin)
+{
+ static char pci_irq_table[][4] =
+ /*
+ * PCI IDSEL/INTPIN->INTLINE
+ * A B C D
+ */
+ {
+ {MPC52xx_IRQ0, MPC52xx_IRQ1, MPC52xx_IRQ2, MPC52xx_IRQ3},
+ {MPC52xx_IRQ1, MPC52xx_IRQ2, MPC52xx_IRQ3, MPC52xx_IRQ0},
+ };
+
+ const long min_idsel = 24, max_idsel = 25, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+#else /* Original Lite */
static int
lite5200_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
{
return (pin == 1) && (idsel==24) ? MPC52xx_IRQ0 : -1;
}
#endif
+#endif
static void __init
lite5200_setup_cpu(void)
@@ -111,6 +132,11 @@ lite5200_setup_cpu(void)
/* Get port mux config */
port_config = in_be32(&gpio->port_config);
+#ifdef CONFIG_LITE5200B
+ /* turn on cs1 */
+ port_config |= 0x80000000;
+#endif
+
/* 48Mhz internal, pin is GPIO */
port_config &= ~0x00800000;
@@ -129,11 +155,17 @@ lite5200_setup_cpu(void)
out_be32(&xlb->config, in_be32(&xlb->config) | MPC52xx_XLB_CFG_SNOOP);
out_be32(&xlb->snoop_window, MPC52xx_PCI_TARGET_MEM | 0x1d);
- /* IRQ[0-3] setup : IRQ0 - Level Active Low */
- /* IRQ[1-3] - Level Active High */
+ /* IRQ[0-3] setup */
intr_ctrl = in_be32(&intr->ctrl);
intr_ctrl &= ~0x00ff0000;
- intr_ctrl |= 0x00c00000;
+#if CONFIG_LITE5200B
+ /* IRQ[0-3] Level Active Low */
+ intr_ctrl |= 0x00ff0000;
+#else
+ /* IRQ0 Level Active Low
+ * IRQ[1-3] Level Active High */
+ intr_ctrl |= 0x00c00000;
+#endif
out_be32(&intr->ctrl, intr_ctrl);
/* Unmap reg zone */
diff --git a/arch/ppc/syslib/mpc52xx_pci.c b/arch/ppc/syslib/mpc52xx_pci.c
index 313c96e..c5bf453 100644
--- a/arch/ppc/syslib/mpc52xx_pci.c
+++ b/arch/ppc/syslib/mpc52xx_pci.c
@@ -227,7 +227,8 @@ mpc52xx_pci_fixup_resources(struct pci_d
/* The PCI Host bridge of MPC52xx has a prefetch memory resource
fixed to 1Gb. Doesn't fit in the resource system so we remove it */
if ( (dev->vendor == PCI_VENDOR_ID_MOTOROLA) &&
- (dev->device == PCI_DEVICE_ID_MOTOROLA_MPC5200) ) {
+ (dev->device == PCI_DEVICE_ID_MOTOROLA_MPC5200
+ || dev->device == PCI_DEVICE_ID_MOTOROLA_MPC5200B) ) {
struct resource *res = &dev->resource[1];
res->start = res->end = res->flags = 0;
}
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ecc1fc1..c16cf15 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -778,6 +778,7 @@
#define PCI_DEVICE_ID_MOTOROLA_HAWK 0x4803
#define PCI_DEVICE_ID_MOTOROLA_HARRIER 0x480b
#define PCI_DEVICE_ID_MOTOROLA_MPC5200 0x5803
+#define PCI_DEVICE_ID_MOTOROLA_MPC5200B 0x5809
#define PCI_VENDOR_ID_PROMISE 0x105a
#define PCI_DEVICE_ID_PROMISE_20265 0x0d30
--
1.1.3
^ permalink raw reply related
* Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: David Hawkins @ 2006-01-24 18:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43CC3E37.4040707@softadvances.com>
Hi all,
I was writing a simple driver to test IRQ handling on the
AMCC Yosemite board. The board has an 8x2 header with several
GPIO pins, a number of which can be configured as IRQ inputs.
I plan to setup GPIO46 as output, and GPIO47 as input, and
select IRQ8 on that pin.
The GPIO46 and GPIO47 are configured via the GPIO1 registers
at 0xEF600C00. U-Boot can be used to read the register values:
=> md ef600c00 b
ef600c00: 00000000 c2000000 50080000 00000000 ........P.......
ef600c10: 00000000 00000000 00000000 3ffcfffd ............?...
ef600c20: 00000000 00000000 00000000 ............
=> md ef600c30 6
ef600c30: 00000400 00000000 00010000 00000000 ................
ef600c40: 00000000 00000000 ........
=>
So
ef600c00 GPIO1_OR = 00000000
ef600c04 GPIO1_TCR = c2000000
ef600c30 GPIO1_ISR1L = 00000400
However, if I read those same registers back under Linux,
using the driver code pasted at the end of this message
I get:
# insmod yosemite_gpio.ko
- remap the GPIO registers
- remapped to address 0xD1008C00
- Read some GPIO1 registers using readl()
- GPIO1_OR = 0x00000000
- GPIO1_TCR = 0x000000C2
- GPIO1_ISR1L = 0x00040000
- Read some GPIO1 registers using ioread32()
- GPIO1_OR = 0x00000000
- GPIO1_TCR = 0x000000C2
- GPIO1_ISR1L = 0x00040000
- Read some GPIO1 registers using an integer pointer
- GPIO1_OR = 0x00000000
- GPIO1_TCR = 0xC2000000
- GPIO1_ISR1L = 0x00000400
readl() and ioread32() read the registers in little-endian format!
Looking at asm-ppc/io.h
- ioread32() is just a readl()
- line 180 (2.6.13) has readl() as in_le32()
(the code is the same in the 2.6.15-denx kernel too)
So, this explains why the data is read in little-endian format,
but not why this was done.
If the processor was reading from the PCI bus, then sure, I
could understand why this might be used, but even then, that
should be up to the user, eg. by using cpu_to_le32 etc.
Should I just be using pointers for remapped processor
registers, and only use readl(), ioread32(), etc, on external
memory?
I know this is just a big-endian/little-endian issue, I'm
really just asking for the driver writing 'best practices'
in this regard.
Looking forward to enlightenment :)
Cheers
Dave
--------------------------driver code----------------------------
/* yosemite_gpio.c */
#include <linux/module.h> /* kernel modules */
#include <asm/io.h> /* ioremap64(), iounmap(), readl() */
static unsigned long long base = 0x0EF600C00; // 36-bit address
static unsigned int size = 0x44;
static char *kernel;
static int __init simple_init(void)
{
int *p;
/* Get the GPIO control registers */
printk(" - remap the GPIO registers\n");
kernel = ioremap64(base, size);
printk(" - remapped to address 0x%.8X\n", (int)kernel);
printk(" - Read some GPIO1 registers using readl()\n");
printk(" - GPIO1_OR = 0x%.8X\n", readl(kernel));
printk(" - GPIO1_TCR = 0x%.8X\n", readl(kernel+0x04));
printk(" - GPIO1_ISR1L = 0x%.8X\n", readl(kernel+0x30));
printk(" - Read some GPIO1 registers using ioread32()\n");
printk(" - GPIO1_OR = 0x%.8X\n", ioread32(kernel));
printk(" - GPIO1_TCR = 0x%.8X\n", ioread32(kernel+0x04));
printk(" - GPIO1_ISR1L = 0x%.8X\n", ioread32(kernel+0x30));
p = (int *)kernel;
printk(" - Read some GPIO1 registers using an integer pointer\n");
printk(" - GPIO1_OR = 0x%.8X\n", p[0]);
printk(" - GPIO1_TCR = 0x%.8X\n", p[1]);
printk(" - GPIO1_ISR1L = 0x%.8X\n", p[12]);
/* Don't load */
iounmap(kernel);
return -EINVAL;
}
module_init(simple_init);
MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH] Add support for lite5200b board.
From: Sylvain Munaut @ 2006-01-24 18:17 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-embedded
In-Reply-To: <43D65FE3.6080501@freescale.com>
Hi John,
John Rigby wrote:
> Sylvain,
>
> Here is an updated patch for the liteb board.
>
> John
Looks good. But two comments :
* Isn't a modif to the arch/ppc/platform/Makefile missing ?
* What's the "cs-1" you turn on there :
>
> +#ifdef CONFIG_LITE5200B
> + /* turn on cs1 */
> + port_config |= 0x80000000;
> +#endif
I couldn't find the schema / real-doc of the Lite5200b,
is this available somewhere on-line ?
Sylvain
^ permalink raw reply
* Yosemite/440EP is there a global interrupt enable mask?
From: David Hawkins @ 2006-01-24 19:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43D66D06.9090904@ovro.caltech.edu>
Hi all,
I'm writing a simple driver to test IRQ handling on the
AMCC Yosemite board. The board has an 8x2 header with several
GPIO pins, a number of which can be configured as IRQ inputs.
I have setup GPIO46 as output, and GPIO47 as input, and
selected IRQ8 on that pin.
The simple driver sets up the IRQ handler, and then drops
into a loop where it pulses the GPIO47 output. The relevent
messages from this loop are:
- Read some GPIO1 registers
- GPIO1_OR = 0x00020000
- GPIO1_TCR = 0xC2020000
- GPIO1_ISR1L = 0x00000401
- enable IRQ8
- UIC1_SR = 0x00002800
- UIC1_ER = 0xE0801008
IRQ8 is bit 19 in the enable register, i.e., 1 << (31-19) = 1000h
So, clearly its enabled here.
- sleep for 1s
- UIC1_SR = 0x00002800
- UIC1_ER = 0xE0801008
And after a sleep for 1s its still enabled.
----- loop test -----
- generate low on GPIO46
- sleep for 10 ticks
- generate high on GPIO46
- UIC1_SR = 0x00003800
- UIC1_ER = 0xE0800008
- IRQ8 status is set, clearing it
- UIC1_SR = 0x00002800
- UIC1_ER = 0xE0800008
- sleep for 10 ticks
... repeats ...
The low pulse on the GPIO46 pin definitely set the IRQ8 status
bit, but why on earth is the enable bit cleared!
(I added the check for the status bit being set, since my
IRQ handler was not getting called)
To enable the IRQ8 line, I simply accessed the UIC1_ER register
directly via
reg = mfdcr(DCRN_UIC_ER(UIC1));
reg |= 1 << (31-19);
mtdcr(DCRN_UIC_ER(UIC1), reg);
So, is there a kernel wide interrupt enable mask that I really
should be using? Or, an interrupt enable API? I initially
thought that when I registered an interrupt using
request_irq() that the kernel would go off an enable the
requested IRQ, but this test shows that it did not.
Any ideas?
Cheers
Dave
--------------- driver code --------------------------
/* yosemite_irq.c */
#include <linux/module.h> /* kernel modules */
#include <linux/interrupt.h>/* request_irq(), etc */
#include <asm/io.h> /* ioremap64(), iounmap(), readl() */
static char *name = "yosemite_irq";
static unsigned long long base = 0x0EF600C00; // 36-bit address
static unsigned int size = 0x44;
static char *kernel;
static int irq = 8;
static irqreturn_t
simple_irq_handler(int irq, void *dev_id, struct pt_regs *regs)
{
int *p = (int *)kernel;
printk("<irq %d> received!\n", irq);
/* Deassert the interrupt input; GPIO1_OR[14] = 1 */
// writel(1<<(31-14), kernel);
p[0] = 1 << (31-14);
/* Clear IRQ8 status (UIC1_SR[19] = 1 to clear it) */
mtdcr(DCRN_UIC_SR(UIC1), 1 << (31-19));
return IRQ_HANDLED;
}
static int __init simple_init(void)
{
int status;
int reg;
int *p;
int i;
printk("<init> called.\n");
/* Get the GPIO control registers */
printk(" - remap the GPIO registers\n");
kernel = ioremap64(base, size);
printk(" - remapped to address 0x%.8X\n", (int)kernel);
p = (int *)kernel;
/* Get the IRQ8 */
printk(" - request the IRQ\n");
status = request_irq(
irq,
simple_irq_handler,
SA_INTERRUPT,
name,
0);
if (status < 0) {
printk(" - request for irq %d failed\n", irq);
return status;
}
printk(" - Read some DCR registers\n");
printk(" - UIC0_SR = 0x%.8X\n", mfdcr(DCRN_UIC_SR(UIC0)));
printk(" - UIC0_ER = 0x%.8X\n", mfdcr(DCRN_UIC_ER(UIC0)));
printk(" - UIC0_PR = 0x%.8X\n", mfdcr(DCRN_UIC_PR(UIC0)));
printk(" - UIC0_TR = 0x%.8X\n", mfdcr(DCRN_UIC_TR(UIC0)));
printk(" - UIC1_SR = 0x%.8X\n", mfdcr(DCRN_UIC_SR(UIC1)));
printk(" - UIC1_ER = 0x%.8X\n", mfdcr(DCRN_UIC_ER(UIC1)));
printk(" - UIC1_PR = 0x%.8X\n", mfdcr(DCRN_UIC_PR(UIC1)));
printk(" - UIC1_TR = 0x%.8X\n", mfdcr(DCRN_UIC_TR(UIC1)));
printk(" - Read some GPIO1 registers\n");
printk(" - GPIO1_OR = 0x%.8X\n", p[0]);
printk(" - GPIO1_TCR = 0x%.8X\n", p[1]);
printk(" - GPIO1_ISR1L = 0x%.8X\n", p[12]);
/* Setup GPIO46 as output. GPIO46 drives GPIO47, and
* GPIO47 will be used as IRQ8. The default IRQ
* sensitivity is low and level sensitive.
*/
printk(" - set GPIO46 as output\n");
/* GPIO1_OR[14] = 1 */
// writel(readl(kernel) | (1 << (31-14)), kernel);
p[0] |= 1 << (31-14);
/* GPIO1_TCR[14] = 1 */
// writel(readl(kernel+0x04) | (1 << (31-14)), kernel+0x04);
p[1] |= 1 << (31-14);
/* Select GPIO47 IRQ8 input */
printk(" - set GPIO47 as IRQ8 input\n");
/* GPIO1_ISR1L[30:31] = 01b */
// writel(readl(kernel+0x30) | 1, kernel+0x30);
p[12] |= 1;
/* Clear IRQ8 status (write 1 to bit 19 to clear it) */
printk(" - clear IRQ8 status\n");
mtdcr(DCRN_UIC_SR(UIC1), 1 << (31-19));
printk(" - Read some GPIO1 registers\n");
printk(" - GPIO1_OR = 0x%.8X\n", p[0]);
printk(" - GPIO1_TCR = 0x%.8X\n", p[1]);
printk(" - GPIO1_ISR1L = 0x%.8X\n", p[12]);
/* Enable IRQ8 */
printk(" - enable IRQ8\n");
reg = mfdcr(DCRN_UIC_ER(UIC1));
reg |= 1 << (31-19);
mtdcr(DCRN_UIC_ER(UIC1), reg);
printk(" - UIC1_SR = 0x%.8X\n", mfdcr(DCRN_UIC_SR(UIC1)));
printk(" - UIC1_ER = 0x%.8X\n", mfdcr(DCRN_UIC_ER(UIC1)));
printk(" - sleep for 1s\n");
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
printk(" - UIC1_SR = 0x%.8X\n", mfdcr(DCRN_UIC_SR(UIC1)));
printk(" - UIC1_ER = 0x%.8X\n", mfdcr(DCRN_UIC_ER(UIC1)));
reg = mfdcr(DCRN_UIC_ER(UIC1));
if ((reg & (1 << (31-19))) == 0) {
printk(" - hey something cleared my enable bit!\n");
return 0;
}
printk(" ----- loop test -----\n");
for (i = 0; i < 5; i++) {
printk(" - generate low on GPIO46\n");
p[0] = 0;
printk(" - sleep for 10 ticks\n");
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(10);
printk(" - generate high on GPIO46\n");
p[0] = 1 << (31-14);
printk(" - UIC1_SR = 0x%.8X\n", mfdcr(DCRN_UIC_SR(UIC1)));
printk(" - UIC1_ER = 0x%.8X\n", mfdcr(DCRN_UIC_ER(UIC1)));
reg = mfdcr(DCRN_UIC_SR(UIC1));
if ((reg & (1 << (31-19))) == 0) {
printk(" - IRQ8 status is not set\n");
} else {
printk(" - IRQ8 status is set, clearing it\n");
mtdcr(DCRN_UIC_SR(UIC1), 1 << (31-19));
}
printk(" - UIC1_SR = 0x%.8X\n", mfdcr(DCRN_UIC_SR(UIC1)));
printk(" - UIC1_ER = 0x%.8X\n", mfdcr(DCRN_UIC_ER(UIC1)));
printk(" - sleep for 10 ticks\n");
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(10);
}
/* log load */
printk("module loaded.\n");
return 0;
}
void __exit simple_exit(void)
{
int reg;
printk("<exit> called.\n");
/* Disable IRQ8 */
reg = mfdcr(DCRN_UIC_ER(UIC1));
reg &= ~(1 << (31-19));
mtdcr(DCRN_UIC_ER(UIC1), reg);
free_irq(irq, 0);
iounmap(kernel);
printk("module unloaded\n");
}
module_init(simple_init);
module_exit(simple_exit);
^ permalink raw reply
* Re: [PATCH 001/001 Updated again] PMAC HD runtime blinking control
From: Benjamin Herrenschmidt @ 2006-01-24 23:14 UTC (permalink / raw)
To: Cedric Pradalier; +Cc: Linuxppc-dev
In-Reply-To: <20060124222513.48ef0276.cedric.pradalier@inrialpes.fr>
On Tue, 2006-01-24 at 22:25 +1000, Cedric Pradalier wrote:
> According to Benjamin Herrenschmidt, on Tue, 24 Jan 2006
> 10:10:26 +1100,
> >On Tue, 2006-01-24 at 07:31 +1000, Cedric Pradalier wrote:
> >> >
> >> >Yes. In fact, by enabled default for ATA disks and by disabled for ATAPI
> >> >would make sense...
> >>
> >> How do I tell the difference?. There is a 'kind' in pmif,
> >> and also a atapi_dma flag in hwif. Which is more sensible?
> >
> >You need to check drive->media ... Which is a bit annoying since it mans
> >it's per drive, not per-HWIF... you may want to move your sysfs entry
> >down one more level :) (Each HWIF has an array of 2 drives, though check
> >drive->present before expecting a useful struct device there)
> >
>
> Well in this case, I'll let this part waiting for now.
> I don't think there will be enough real users of this minor
> thing to justify putting any more efforts for now.
>
> I think the practical solution is to disable the led by
> default. The few user who will want it will be able to add
> either ide_core.blink to their boot parameter or make a
> small init.d script to put 1 into the sysfs entry.
>
> That's the way I've implemented it, and I've changed the
> name into activity_led.
I'll have a look into making it work he way I want :) Then I'll submit
it.
Thanks,
Ben.
> pradalier@localhost:~$ find /sys/ -name activity_led
> /sys/devices/pci0001:10/0001:10:17.0/0.80000000:mac-io/0.0001f000:ata-4/ide0/activity_led
>
> This is the updated version of the patch. I, for one, will
> consider it stable now.
>
> signed-off-by: Cedric Pradalier <cedric.pradalier@free.fr>
> ---
> --- drivers/ide/ppc/pmac.c.orig 2006-01-03 13:21:10.000000000 +1000
> +++ drivers/ide/ppc/pmac.c 2006-01-24 21:18:36.000000000 +1000
> @@ -36,6 +36,11 @@
> #include <linux/pmu.h>
> #include <linux/scatterlist.h>
>
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> +#include <linux/device.h>
> +#include <asm/of_device.h>
> +#endif
> +
> #include <asm/prom.h>
> #include <asm/io.h>
> #include <asm/dbdma.h>
> @@ -427,6 +432,15 @@ static void pmac_ide_kauai_selectproc(id
>
> #ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
>
> +MODULE_AUTHOR("Paul Mackerras & Ben. Herrenschmidt");
> +MODULE_DESCRIPTION("Support for IDE interfaces on PowerMacs");
> +MODULE_LICENSE("GPL");
> +
> +static int activity_led = 0;
> +module_param_named(blink,activity_led, bool, 0666);
> +MODULE_PARM_DESC(blink,"Enable/Disable activity led [Default: disabled]");
> +
> +
> /* Set to 50ms minimum led-on time (also used to limit frequency
> * of requests sent to the PMU
> */
> @@ -437,8 +451,7 @@ static spinlock_t pmu_blink_lock;
> static unsigned long pmu_blink_stoptime;
> static int pmu_blink_ledstate;
> static struct timer_list pmu_blink_timer;
> -static int pmu_ide_blink_enabled;
> -
> +static int pmu_ide_blink_enabled = 0;
>
> static void
> pmu_hd_blink_timeout(unsigned long data)
> @@ -468,6 +481,8 @@ static void
> pmu_hd_kick_blink(void *data, int rw)
> {
> unsigned long flags;
> + if (!activity_led)
> + return;
>
> pmu_blink_stoptime = jiffies + PMU_HD_BLINK_TIME;
> wmb();
> @@ -483,6 +498,26 @@ pmu_hd_kick_blink(void *data, int rw)
> spin_unlock_irqrestore(&pmu_blink_lock, flags);
> }
>
> +static ssize_t show_activity_led_enable(struct device *dev, struct device_attribute *attr, char *buf)\
> +{
> + return sprintf(buf, "%c\n", activity_led?'1':'0');
> +}
> +
> +static ssize_t set_activity_led_enable(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int blink=0;
> + if (sscanf (buf, "%d", &blink) != 1)
> + return -EINVAL;
> + activity_led = (blink != 0);
> + printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
> + activity_led?"enabled":"disabled");
> + return count;
> +}
> +
> +static DEVICE_ATTR (activity_led, S_IRUGO | S_IWUSR,
> + show_activity_led_enable, set_activity_led_enable);
> +
> static int
> pmu_hd_blink_init(void)
> {
> @@ -516,6 +551,9 @@ pmu_hd_blink_init(void)
> init_timer(&pmu_blink_timer);
> pmu_blink_timer.function = pmu_hd_blink_timeout;
>
> + printk(KERN_INFO "pmac blinking led initialized (blink %s)\n",
> + activity_led?"enabled":"disabled");
> +
> return 1;
> }
>
> @@ -1271,7 +1309,7 @@ static int
> pmac_ide_setup_device(pmac_ide_hwif_t *pmif, ide_hwif_t *hwif)
> {
> struct device_node *np = pmif->node;
> - int *bidp, i;
> + int *bidp;
>
> pmif->cable_80 = 0;
> pmif->broken_dma = pmif->broken_dma_warn = 0;
> @@ -1401,6 +1439,12 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
> /* We probe the hwif now */
> probe_hwif_init(hwif);
>
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
> + /* We wait till here to have the gendev initialized in hwif */
> + device_create_file (&hwif->gendev, &dev_attr_activity_led);
> +#endif
> +
> +
> return 0;
> }
>
^ permalink raw reply
* Help: FCC driver does not handle IPV6 multicast packet
From: Bizhan Gholikhamseh (bgholikh) @ 2006-01-25 0:14 UTC (permalink / raw)
To: linuxppc-embedded, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
HI All,
Our custom board is based on PPC 8541 running Linux 2.6.11.
We have NO issue if FCC is operating in 100 Mbs. However, if we
configure the interface in 10 Mbs we see the following behavior:
If IPV6 is enabled, as soon as the FCC network interface is plumbed
through "ifconfig" system call, we observe the CPU load increases to 90
percent
and most of the load is related to softirq process. A traceroute command
on the interface displays an IPV6 multicast packet continuously getting
transmitted.
If we bring the interface down through the ifconfig, we do not observe
the problem
no longer. The strange thing is we do not observe this behavior if the
interface
is plumbed 100 Mbs.
We need to root cause this and have no idea what to look for, any idea
greatly
appreciated.
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 2760 bytes --]
^ permalink raw reply
* Linux kernel and u-boot debugging with Eclipse IDE
From: IGOR LURI @ 2006-01-25 7:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
Hi all,
We have a MPC5200Lite board running Linux 2.4.25 and u-boot 1.1.4. We are able to debug Linux kernel and U-boot using DDD/GDB and BDI2000, and we are trying to use Eclipse IDE (with CDT plugin) / BDI2000 to develop and debug software.
Eclipse works well to remote debugging aplications over ethernet, however, we are not able to debug Linux kernel or u-boot using Eclipse. When it stops in the first breakpoint, I can´t view some variables and stepping into a function, it shows another. It seems that Eclipse has problems with Linux kernel and u-boot symbols.
Someone uses Eclipse and BDI2000 to debug Linux kernel and u-boot?
Igor Luri
R&D Software Department
Fagor Automation S. Coop.
[-- Attachment #2: Type: text/html, Size: 1398 bytes --]
^ permalink raw reply
* Re: [FIXED] Trouble with SMC serial port in ppc/boot/simple on Embedded Planet 8248 board
From: Laurent Pinchart @ 2006-01-25 9:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200601240926.14408.laurent.pinchart@tbox.biz>
Hi,
I've been able to fix the problem. I made a mistake in Linux boot code
(ppc/boot/simple/embed_config.c) when computing the amount of available RAM,
which resulted in Linux thinking it could access -16MB = 4080MB of RAM.
Laurent Pinchart
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: Stefan Roese @ 2006-01-25 9:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43D66D06.9090904@ovro.caltech.edu>
Hi David,
On Tuesday 24 January 2006 19:08, David Hawkins wrote:
> readl() and ioread32() read the registers in little-endian format!
Correct. That's how it is implemented on all platforms. Think for example of
an pci device driver. Using these IO functions, the driver will become
platform independent, running without modifications on little- and big-endian
machines.
> If the processor was reading from the PCI bus, then sure, I
> could understand why this might be used, but even then, that
> should be up to the user, eg. by using cpu_to_le32 etc.
No. Please see above.
> Should I just be using pointers for remapped processor
> registers, and only use readl(), ioread32(), etc, on external
> memory?
That's how I do it. Only use readl() and friends for pci spaces (or other
little endian memory mapped areas).
Best regards,
Stefan
^ permalink raw reply
* Re: Yosemite/440EP is there a global interrupt enable mask?
From: Stefan Roese @ 2006-01-25 10:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43D67AF6.6070403@ovro.caltech.edu>
Hi David,
On Tuesday 24 January 2006 20:07, David Hawkins wrote:
> I'm writing a simple driver to test IRQ handling on the
> AMCC Yosemite board. The board has an 8x2 header with several
> GPIO pins, a number of which can be configured as IRQ inputs.
>
> I have setup GPIO46 as output, and GPIO47 as input, and
> selected IRQ8 on that pin.
OK. So far good.
<snip>
> So, is there a kernel wide interrupt enable mask that I really
> should be using? Or, an interrupt enable API? I initially
> thought that when I registered an interrupt using
> request_irq() that the kernel would go off an enable the
> requested IRQ, but this test shows that it did not.
Yes, the request_irq() should enable the requested IRQ. You seem to have used
the wrong IRQ number though. Please see below.
> #include <linux/module.h> /* kernel modules */
> #include <linux/interrupt.h>/* request_irq(), etc */
> #include <asm/io.h> /* ioremap64(), iounmap(), readl() */
>
> static char *name = "yosemite_irq";
> static unsigned long long base = 0x0EF600C00; // 36-bit address
> static unsigned int size = 0x44;
> static char *kernel;
> static int irq = 8;
You are using the "External IRQ 8". This results in IRQ number 19 of the 2nd
interrupt controller of the 440ep. So please try (19+32) as the IRQ number
upon requesting the interrupt.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] Add support for lite5200b board.
From: Txema Lopez @ 2006-01-25 10:24 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: John Rigby, linuxppc-embedded
In-Reply-To: <43D66F54.8000404@246tNt.com>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
Hi ,
Sylvain Munaut wrote:
>Hi John,
>
>John Rigby wrote:
>
>
>>Sylvain,
>>
>>Here is an updated patch for the liteb board.
>>
>>John
>>
>>
>
>
>
We have a Lite5200b and are very interesting in this point.
For wich kernel version is this patch?
>Looks good. But two comments :
>
> * Isn't a modif to the arch/ppc/platform/Makefile missing ?
> * What's the "cs-1" you turn on there :
>
>
>
>>
>>+#ifdef CONFIG_LITE5200B
>>+ /* turn on cs1 */
>>+ port_config |= 0x80000000;
>>+#endif
>>
>>
>
>
>
What fix this ?
> I couldn't find the schema / real-doc of the Lite5200b,
>is this available somewhere on-line ?
>
>
>
>
>
Sylvain, I don't know if there are some Lite5200b doc on line, but I
have the schematics and could send to you or to anyone who want it.
> Sylvain
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[-- Attachment #2: tlopez.vcf --]
[-- Type: text/x-vcard, Size: 324 bytes --]
begin:vcard
fn:Jose Maria Lopez
n:Lopez;Jose Maria
org:Fagor Automation S. Coop.
adr:;;San Andres 19. Apdo. 144;Arrasate-Mondragon;;20500;Spain
email;internet:tlopez@aotek.es
title:Sotware engineer
tel;work:(34) 943719200
tel;fax:(34) 943791712
x-mozilla-html:FALSE
url:http://www.fagorautomation.es
version:2.1
end:vcard
^ 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