* Re: Linux controlling Hardware-Tasks on FPGA
From: David Hawkins @ 2006-07-19 16:15 UTC (permalink / raw)
To: Josef Angermeier; +Cc: linuxppc-embedded
In-Reply-To: <44BDDFD2.9040702@cs.fau.de>
> anyone else out there using or wanting to use Linux to control the
> reconfiguration of a FPGA ? - Do you use dynamic partial reconfiguration
> too ? - If so how did you design the relevant software coarsely ?
Hi Josef,
If you are talking 'partial reconfiguration' then I guess you
are discussing Xilinx devices.
I use Altera devices in my designs. However, this solution could
work for you.
Generally an FPGA is configured, and I assume reconfigured,
by writing the configuration file to a specific set of pins
on the device. Altera devices have passive serial programming
and fast passive parallel programming (and other options).
In my current design I will create either a /dev entry or
use a /sys/firmware type interface that when opened
initializes the programming logic, and then writes whatever
bytes are written to the filesystem node to the programming
interface, eg. so the following will program the FPGA
dd if=firmware.bin of=/dev/fpga
If I get a programming error, then the driver can just return
-EIO, and I'm pretty sure dd will report the error. I plan
to use this approach as I can then buffer the data from user-space
into a kernel buffer, and then setup a DMA controller to
write to the device node. This will ensure that burst transactions
are used (to a system controller FPGA sitting on the local bus
of a PowerQUICC II Pro).
The alternative is to implement mmap() for the region containing
your programming interface control registers, and then just
bit- or byte-bang the programming interface. However, if the
serial interface is slow, then you could turn your 100MHz+ CPU
into a 1MHz- CPU. Linux sometimes has trouble with this
(I've seen the x86 kernel lose ticks when performing lots of
PCI I/O, so now use DMA when its available - which for x86
is basically never, so you have to depend on the adapter board).
Hope that gives you some ideas.
Regards
Dave
^ permalink raw reply
* Re: reboot on PQ2FADS board.
From: Mathieu Deschamps @ 2006-07-19 16:41 UTC (permalink / raw)
To: Lei Sun; +Cc: linuxppc-embedded
In-Reply-To: <f9a7e7a80607190712v362c3e1ei7e85003041a25e35@mail.gmail.com>
Hi,
On Wednesday 19 July 2006 16:12, Lei Sun wrote:
> Hi :
> I tried your approach last ight, (in fact I copied part of the
> do_reboot() code from u-boot and put it in m8260_restart() function in
> the kernel). The only difference is the first line,
> volatile immap_t *immap = (immap_t *) IMAP_ADDR;
> in my case it is
> volatile immap_t * immap = cpm2_immr;
> I am using different source tree.
> it simply hangs, rather then reset.
>
[...]
Give a try to :
startaddr = 0xff000104;
--
Mathieu Deschamps
Com2gether Design Center
Electronic and Embedded Engineering Services
www.com2gether.net
^ permalink raw reply
* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-07-19 16:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3140C9D90FB6D911ABD7000F206DC92603D6E0FC@zhk08exm40.ap.freescale.net>
Hi Jeffrey,
> I have done the PCI config cycle under u-boot. This is very simple
and > able to find the PEX EP attached to the MPC8548.
> In this log, it is reading a pair of MPC8548E connected together
using > PEX.
> Please see the log below:
[ ... ]
thanks for sharing this piece of information.
I will investigate if this matches the way it is done in the kernel.
Thanks,
Florian
Ho Jeffrey-r26191 schrieb:
> Hi Florian,
>
>
> U-Boot 1.1.4 (Apr 12 2006 - 11:40:53)
>
> CPU: 8548_E, Version: 1.1, (0x80390011)
> Core: e500v2, Version: 1.0, (0x80210010)
> Clock Configuration:
> CPU:1333 MHz, CCB: 533 MHz,
> DDR: 266 MHz, LBC: 33 MHz
> L1: D-cache 32 kB enabled
> I-cache 32 kB enabled
>
> Board: MPC85xx Processor Card Rev. A.
> -- Boot Flash is U30
>
> SRIO: X4 2.5Gbps
> PEX : X4 2.5Gbps
> PCI1: 32 bit, async
> PCI2: disabled
> I2C: ready
> DRAM: Initializing
> DDR: 256 MB
> FLASH: 16 MB
> L2 cache 512KB: enabled
> In: serial
> Out: serial
> Err: serial
> Net: eTSEC0: PHY is Marvell 88E1111S (1410cc1)
> eTSEC1: PHY is Realtek RTL821x (1cc912)
> eTSEC2: PHY is Marvell 88E1111S (1410cc1)
> eTSEC3: PHY id ffffffff is not supported!
> eTSEC0, eTSEC1, eTSEC2 [PRIME], eTSEC3
> eTSEC0 & eTSEC1 in Reduce mode
> eTSEC2 & eTSEC3 in Reduce mode
> Hit any key to stop autoboot: 0
> MPC8548E_Rev1.1=> mm e000a000 <-setup command register
> e000a000: 8000f800 ? 80000004 Bus master, SERR, Memory space
> e000a004: 02001000 ? 06011000
> e000a008: 00000000 ? .
> MPC8548E_Rev1.1=> mm e000a000 <-Set secondary bus num = 1
> e000a000: 80000004 ? 80000018 Subordinate bus num = 3
> e000a004: 00000000 ? 00010300
> e000a008: 00000000 ? .
> MPC8548E_Rev1.1=> mm e000a000 <-Check PEX agent ID
> e000a000: 80000018 ? 80010000
> e000a004: 57191200 ? .
> MPC8548E_Rev1.1=> mm e000a000 <-Set PEX agent BAR0 (PEXCSRBAR)
> e000a000: 80010010 ? 80010010 PEXCSRBAR = 0x80000000
> e000a004: 00000000 ? 00000080 This is the PCI address space
> e000a008: 00000000 ? .
> MPC8548E_Rev1.1=> mm e000a000 <-Set PEX agent command register
> e000a000: 80010014 ? 80010004 Bus master, SERR, Memory space
> e000a004: 00001000 ? 06011000
> e000a008: 00000000 ? .
> MPC8548E_Rev1.1=>
> mw e000ac20 00080000; <-Set TAR = 0x80000000 (PCI address space)
> mw e000ac24 0; <-Set 32:64bit TAR = 0x0 (PCI address space)
> mw e000ac28 000a0000; <-Set WBA = 0xa0000000 (ECM, e500 address space)
> mw e000ac30 8004401A <-Set normal R/W, enable Outbound window
> MPC8548E_Rev1.1=>
> MPC8548E_Rev1.1=>
> MPC8548E_Rev1.1=> mm e000a000 <-check PEX agent BAR0 if written
> e000a000: 80010010 ?
> e000a004: 00000080 ? .
> MPC8548E_Rev1.1=> md a0000000 <-read PEX agent CCSRBAR address use 0xa0000000
> a0000000: 000ff700 00000000 00000000 00000000 ................
> a0000010: 00000000 00000000 00000000 00000000 ................
> a0000020: 00000000 00000000 00000000 00000000 ................
> a0000030: 00000000 00000000 00000000 00000000 ................
> a0000040: 00000000 00000000 00000000 00000000 ................
> a0000050: 00000000 00000000 00000000 00000000 ................
> a0000060: 00000000 00000000 00000000 00000000 ................
> a0000070: 00000000 00000000 00000000 00000000 ................
> a0000080: 00000000 00000000 00000000 00000000 ................
> a0000090: 00000000 00000000 00000000 00000000 ................
> a00000a0: 00000000 00000000 00000000 00000000 ................
> a00000b0: 00000000 00000000 00000000 00000000 ................
> a00000c0: 00000000 00000000 00000000 00000000 ................
> a00000d0: 00000000 00000000 00000000 00000000 ................
> a00000e0: 00000000 00000000 00000000 00000000 ................
> a00000f0: 00000000 00000000 00000000 00000000 ................
>
> Regards,
> Jeffrey Ho
> Freescale Semiconductor HK Ltd
> Tel: 852-26668050
>
>
>> -----Original Message-----
>> From:
>> linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.org
>> [mailto:linuxppc-embedded-bounces+r26191=freescale.com@ozlabs.
>> org] On Behalf Of Florian Boelstler
>> Sent: Monday, June 26, 2006 6:48 PM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
>>
>> Hi,
>>
>> I am currently working on a MPC8548-based development system.
>> Linux kernel version is 2.6.11 with patches delivered from
>> Freescale (BSP MPC8548CDS 02/24/2006).
>>
>> Kernel configuration contains a warning message for CONFIG_PEX:
>> "This requires hardware modification to work correctly if
>> your CPU version < 2.0 and will break the PCI bus. [...]"
>>
>> I was wondering whether enabling PCIe makes PCI bus
>> functionality unusable at all (including kernel functionality
>> for detecting devices behind a transparent PCI-to-PCI bridge).
>>
>> Our setup connects a transparent PLX8516 PCI-to-PCI bridge to
>> the PCIe port of the MPC8548 daughter board. Behind that
>> bridge is another PCIe capable device.
>> MPC8548 is configured to run as PCIe host mode.
>>
>> When trying to lookup the PCIe devices using lspci I can only
>> see the PPC itself and the bridge.
>> However I cannot see the device(s) behind the bridge.
>>
>> Is there another method for detecting PCI(e) devices?
>> Is "BSP MPC8548CDS 02/24/2006" the latest version
>> corresponding to that hardware?
>>
>> Thanks in advance,
>>
>> Florian
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
^ permalink raw reply
* Re: Kexec initial registers
From: Milton Miller @ 2006-07-19 17:17 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <1152911297.23037.109.camel@localhost.localdomain>
On Jul 14, 2006, at 5:08 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2006-07-14 at 12:02 -0400, Jimi Xenidis wrote:
>> This is what I have so far:
The processor will be in real mode. (well, whatever that means for book-e)
>>
>> r3: address of device tree blob
>> r4: address that kernel was loaded
mostly, see below.
>> r5: not OF (=0)
>
> Correct and that's all that should be needed
>
For single processor.
>> r13: local_paca address (0?)
>
> You shouldn't have to care about r13 at all, it should be set by the
> kernel before it's used. If not, please let us know as that means
> there
> is a bug :)
[Mike Ellerman pointed out a recient patch to fix one such bug].
>> Did I miss the document on this?
The documentation for kexec is in arch/powerpc/kernel/misc_64.S in
the middle of kexec_sequence. The documentation for the kernel
entry point is at Documentation/powerpc/booting-without-of.txt.
On the elected master cpu, r4 contains the address of the entry point.
Upon leaving the kernel r3 contains the hardware cpu identifier, and
r5 is 0 to say there is no of interface and r3 and r4 are valid. Both
v2wrap.S and the standard kexec-tools purgatory code store this value
in the device tree struct header and point r3 to the header, which is
the entry requirement for the linux kerne.
To support multi-processor, 256 (0x100) bytes are copied from the
the entry point to address 0, r3 is loaded with the hardware cpu
id corresponding to a node in the device tree and execution of the
slave is at absolute 0x60. Other than being in real mode, the only
state on a slave is r3 and the entry point. Specifically, r4 and
r5 are unspecified.
Unfornately current kexec-tools doesnn't seem to look for the entry
point of the loaded image and assumes it is offset zero. This
creates an unfornate limitation that I only reciently discovered,
and I hope someone will fix it.
Today the register state only applies to the PowerPC 64 bit interface;
the game cube is the only 32 bit port I am aware of and they didn't
have the multi-processor issues. However, I expect 32 bit will
gain this interface well.
Histoory and Background:
Kexec went though some design refinement before it got merged. Part
of this was standardization of the kexec syscall across architectures,
and part was moving to a concept of intermediate wrappers the any
environment setup required for the loaded image. Kexec is supposed
to be able to load any code image and not be tied to loading a linux
kernel. It was declared the only state at the end of the kernel
kexec implmentation would be specified memory contents, processor
execution mode, and entry point. The entry point and memory contents
are specified explictily; the execution mode defaults to the
instruction set and word size of the kernel. While any elf platform
type can be specified the kernel will likely only support only one
(native) or possbly two (for example a 32 bit mode may be added).
All setup of registers, mmu, and any other environment shall be
done in code inserted by kexec-tools or other kexec_load callers.
In kexec-tools, this stage is called purgatory (its neither here
nor there); it is built seperately and embedded in the kexec program.
The register state and other enviornmental parameters is patched
into the image before calling the kexec_load syscall).
Unfornately this would not quite meet the needs of multiprocessor
PowerPC platforms. On x86 other processors have executed an interrupt
disabled halt instruction and therefore are waiting for a NMI or
"init". Unlike x86, PowerPC does not guarantee a way to stop
execution of a processor. How to start a secondary cpu is platform
specific. Not all platforms have a park method that is reversable.
A way was needed to park the slaves. In addition, there is no cross
platform way to determine which cpu you are executing on.
I chose the method that the kernel already did between the prom
code and the main kernel to solve both problems. Copy 256 bytes
to zero, specifiy a second entry point of address 0x60 after the
copy, and specify r3 has the hardware id.
While having r3 point to the device-tree structure on the master
thread might seem to simplify the handoff, there were several
problems. First, there is no method to pass the address of the
structure to the kernel. I realized this was limiting to images
that wanted the kernel's device tree structure and not in the load
anything, setup the environment using code added to the memory image,
design point of kexec. Passing the the hardware identifier
was the minimum requirement. And passing it in r3 is the obvious
choice, both because that is what the slaves needed and it is the
first argument on many calling conventions.
Because branching to an arbitrary address requires loading
said address into a general purpose register I decided that specifing
that register would be r4 would have minimal impact to any code.
And specifiying r5 be zero was purely gratitious, but its one
instruction.
One other difference in the PowerPC 64 bit kexec is that, due to
the limited addressability of memory in real mode in partitions
(HV=0), the initial copy is done with the mmu using the base kernel
and therefore the destination memory can not overlap it or the mmu
page table. If an image requires memory in these areas to be
initialized, then some code must be added to purgatory; the linux
kernel already had the needed copy loop because of our interaction
with open firmware in prom_init.c and that was exploited. In
addition, pSeries tce tables and RTAS are protected.
milton
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Dan Malek @ 2006-07-19 15:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <4856A73A-BB23-4850-A697-1CE7C385DE42@kernel.crashing.org>
On Jul 19, 2006, at 9:14 AM, Kumar Gala wrote:
> This is an incorrect assumption. Its more often that people dont
> post their ports to the Linux kernel for acceptance. We will
> accept any port that is willing to work with the community. for
> example
I agree. The customers of board ports I've done over the years
are always eager to get these into the public sources. It just
seems we run out of time during the pressure of trying to get
the products done, and they just issue them on CDs or for
download afterward.
Thanks.
-- Dan
^ permalink raw reply
* Re: AltiVec in the kernel
From: Linas Vepstas @ 2006-07-19 18:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: 'linuxppc-dev list'
In-Reply-To: <17597.8378.972640.464219@cargo.ozlabs.ibm.com>
On Wed, Jul 19, 2006 at 03:56:10AM +1000, Paul Mackerras wrote:
> A lot of compression and encryption algorithms, by their very nature,
> are very difficult to parallelize enough to get any significant
> improvement from altivec. I looked at SHA1 for instance, and the
> sequential dependencies in the computation are such that it is
> practically impossible to find a way to do 4 things in parallel. The
> sequential dependencies are of course a critical part of the way that
> SHA1 ensures that a small change in any part of the input data results
> in substantial changes in every byte of the output.
But perhaps, in principle, couldn't one run four independent streams
in parallel? Thus, for example, on an SSL-enabled web server, one
could service multiple encryption/decryption threads at once.
In practice, I don't beleive the infrastructure for that kind of
parallelism is in place. I'm struggling to find a reason to develop
that kind of infrastructure. Mumble something about Cell.
> I think that there are actually very few places in the kernel where we
> are doing something which is parallelizable, sufficiently
> compute-intensive, and not bound by memory bandwidth, to be worth
> using altivec.
Yes.
As to non-kernel applications, is there anything for GMP (the
Gnu Multi-Precision library, an arbitrary-precision math library)
on the Altivec? How aout the Cell?
--linas
^ permalink raw reply
* Re: AltiVec in the kernel
From: Paul Mackerras @ 2006-07-19 18:19 UTC (permalink / raw)
To: Linas Vepstas; +Cc: 'linuxppc-dev list'
In-Reply-To: <20060719181047.GL5905@austin.ibm.com>
Linas Vepstas writes:
> But perhaps, in principle, couldn't one run four independent streams
> in parallel? Thus, for example, on an SSL-enabled web server, one
> could service multiple encryption/decryption threads at once.
Generally that would work. If one had 4 separate streams to compute a
SHA1 of, one could do all 4 at once with altivec. It would have to be
4 separate streams though, not 4 parts of a single stream.
> As to non-kernel applications, is there anything for GMP (the
> Gnu Multi-Precision library, an arbitrary-precision math library)
> on the Altivec? How aout the Cell?
I don't really know, sorry.
Paul.
^ permalink raw reply
* Re: MPC8260 SCC UART hardware flow control
From: Wolfgang Denk @ 2006-07-19 18:37 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200607191718.00328.laurent.pinchart@tbox.biz>
In message <200607191718.00328.laurent.pinchart@tbox.biz> you wrote:
>
> I was wondering if anyone had implemented hardware flow control support in the
> cpm_uart driver. If not, I would appreciate pointers regarding how to do so.
You can probably take our 2.4 kernel code as a starting point. But be
aware of the inherent restrictions of the CPM, see
http://www.denx.de/wiki/view/DULG/UseSCCUARTWithHardwareHandshake
[In the end, you might want to configure the handshake signals as
GPIO lines and controll these manually. But then you will have to ask
yourself why you are using a CPM...]
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 average woman would rather have beauty than brains, because the
average man can see better than he can think.
^ permalink raw reply
* Re: AltiVec in the kernel
From: Johannes Berg @ 2006-07-19 18:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: 'linuxppc-dev list'
In-Reply-To: <17598.30626.663773.229019@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
On Thu, 2006-07-20 at 04:19 +1000, Paul Mackerras wrote:
> Linas Vepstas writes:
>
> > But perhaps, in principle, couldn't one run four independent streams
> > in parallel? Thus, for example, on an SSL-enabled web server, one
> > could service multiple encryption/decryption threads at once.
>
> Generally that would work. If one had 4 separate streams to compute a
> SHA1 of, one could do all 4 at once with altivec. It would have to be
> 4 separate streams though, not 4 parts of a single stream.
I'd think it'd be pretty hard to get a real benefit from this because
the data is going to come from 4 totally different places, hence you
can't just load a single vector register and get data for all 4
streams...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Li Yang @ 2006-07-19 18:59 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <1E6652B1-3126-4B69-BE9D-8DCE8DCACE7C@embeddedalley.com>
On 7/19/06, Dan Malek <dan@embeddedalley.com> wrote:
>
> On Jul 19, 2006, at 9:14 AM, Kumar Gala wrote:
>
> > This is an incorrect assumption. Its more often that people dont
> > post their ports to the Linux kernel for acceptance. We will
> > accept any port that is willing to work with the community. for
> > example
>
> I agree. The customers of board ports I've done over the years
> are always eager to get these into the public sources. It just
> seems we run out of time during the pressure of trying to get
> the products done, and they just issue them on CDs or for
> download afterward.
But why? Most embedded products facing end-user wouldn't like users
to modify the system by themselves. Sometimes they even put effort in
preventing user to do so. If no one else is going to modify the code,
what is the value of putting them in public sources? Just to show the
compliance with GPL? The only kind of products I can think of, which
want the users to modify the code is reference boards, IMHO. Please
correct me if I'm wrong.
^ permalink raw reply
* export-objs in spi Makefile broke in latest linuxppc_2_4_devel?
From: Rowan, Chad @ 2006-07-19 19:01 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
Shouldn't export-objs in drivers\spi be:
export-objs := spi-core.o spi-algo-mpc5xxx.o
spi-algo-mpc5xxx-psc.o \
spi-iti5200.o spi-eval.o
instead of:
export-objs := spi-core.o spi-algo-mpc5xxx.o
spi-algo-mpc5200psc.o \
spi-iti5200.o spi-eval.o
[-- Attachment #2: Type: text/html, Size: 3120 bytes --]
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
From: Pete Zaitcev @ 2006-07-19 19:19 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, zaitcev, linux-usb-devel
In-Reply-To: <a0bc9bf80607191159l679ce8ddm35a30236a9d887c7@mail.gmail.com>
On Thu, 20 Jul 2006 02:59:44 +0800, "Li Yang" <LeoLi@freescale.com> wrote:
> But why? Most embedded products facing end-user wouldn't like users
> to modify the system by themselves.
Certainly vendors won't like to give consumers extra freedoms.
However, consumers like those freedoms, even if they would not
use them in any specific instance.
> Sometimes they even put effort in preventing user to do so.
Jerks and criminals, that's what they are. Why would Linux developers
care about needs of these people?
Free software is about protecting the rights of users against
vendors who "wouldn't like" users doing what they want with the
product they bought.
> The only kind of products I can think of, which
> want the users to modify the code is reference boards, IMHO.
Ever heard of WRT54? But in fact, every product out there may provide
its owner an additional value when customized. I'd love to fix some
bugs in my microwave, for instance. The silly thing will not start
the timer if the door is open. It probably uses the same function
which prevents cooking from starting (it also has a hardware interlock
that cuts the magnetron, but this is different).
-- Pete
^ permalink raw reply
* Re: AltiVec in the kernel
From: Linas Vepstas @ 2006-07-19 18:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: 'linuxppc-dev list', Paul Mackerras
In-Reply-To: <1153334301.2546.40.camel@johannes.berg>
On Wed, Jul 19, 2006 at 08:38:21PM +0200, Johannes Berg wrote:
> On Thu, 2006-07-20 at 04:19 +1000, Paul Mackerras wrote:
> > Linas Vepstas writes:
> >
> > > But perhaps, in principle, couldn't one run four independent streams
> > > in parallel? Thus, for example, on an SSL-enabled web server, one
> > > could service multiple encryption/decryption threads at once.
> >
> > Generally that would work. If one had 4 separate streams to compute a
> > SHA1 of, one could do all 4 at once with altivec. It would have to be
> > 4 separate streams though, not 4 parts of a single stream.
>
> I'd think it'd be pretty hard to get a real benefit from this because
> the data is going to come from 4 totally different places, hence you
> can't just load a single vector register and get data for all 4
> streams...
Dohh. Right. I actually thought that while writing the email, and then
it eveporated from my head before I hit the send button. One would
have to copy the incoming data into vectors, and the mem access latency
would probably overwhelm the performance gain (per "hot cache" as Paul
discussed).
--linas
^ permalink raw reply
* export-objs in spi Makefile broke in latest linuxppc_2_4_devel [r eposted]?
From: Rowan, Chad @ 2006-07-19 19:13 UTC (permalink / raw)
To: linuxppc-embedded
Shouldn't export-objs in drivers/spi be:
export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5xxx-psc.o \
spi-iti5200.o spi-eval.o
instead of:
export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5200psc.o \
spi-iti5200.o spi-eval.o
I believe the spi-algo-mpc5200psc.o should be spi-algo-mpc5xxx-psc.o,
correct?
Excuse the previous post. Office, hosed the format.
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Guennadi Liakhovetski @ 2006-07-19 20:02 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060523005846.GA15797@mag.az.mvista.com>
Mark, Ben,
On Mon, 22 May 2006, Mark A. Greer wrote:
> Thanks for your time, Ben. Sorry for taking so long to get back to you.
don't have much to comment to specific points, but quoting the entire
discussion below in case you'll want to further add to it.
What's the status of this work? Mark, have you been further working on
your port? I'd like to integrate kurobox/linkstation support with
sandpoint (also 8241). I think, it would be very interesting as it would
allow us to develop / test the "universal" kernel idea, and at the same
time explore the limits of board-specific support. Kurobox have a couple
of very nice "specialities", like a serially attached AVR acting as a
power-manager, thus requiring __special__ halt and reboot callbacks (so,
please, Ben, don't remove them).
Any progress with fdt-parsing library for the wrapper / kernel and with
replacing hard-coded constants and tables with dt-entries?
I'd love to discuss the stuff and come to an acceptable design / APIs.
Thanks
Guennadi
> For the record, this patch was only a hack that I've done to get a sandpoint
> up ASAP. I should have made it clear to not take Kconfig, etc. stuffs very
> seriously. I was more worried about how we should fit flattened dt into the
> bootwrapper.
>
> I'm glad you did look at it so closely though and bring up a lot of good
> questions. I'm not familiar with 64-bit platforms so all of my babbling
> below is based on my 32-bit platform knowledge.
>
> Mark
> ---
>
> On Thu, May 18, 2006 at 03:32:55PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
>
> <snip>
>
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index 6729c98..de09eac 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -323,7 +323,10 @@ config PPC_ISERIES
> > >
> > > config EMBEDDED6xx
> > > bool "Embedded 6xx/7xx/7xxx-based board"
> > > - depends on PPC32 && BROKEN
> > > + depends on PPC32
> > > + select PPC_UDBG_16550
> > > + select MPIC
> > > + select MPIC_SERIAL
> >
> > Not totally related to your patch but I'm tempted to turn that into a
> > "Generic 6xx/7xx/7xxx" rather than "embedded" if we manage to always
> > avoid board specific code most of the time, but instead add necessary
> > bits in the device-tree. We still need a per-board Kconfig option I
> > think that will just select the necessary bits and pieces (and more than
> > one can be selected at one time). Also, I think right now, the embedded
> > stuff is +/- exclusive from the MULTIPLATFORM stuff, that must be fixed
> > asap. We are all living in the same kernel now :)
>
> OK.
>
> > > +
> > > +config MPIC_SERIAL
> > > + depends on EMBEDDED6xx
> > > + bool
> > > + default n
> >
> > Not sure what the above is, I'll have a look further in the patch but I
> > can already tell you that it should be your per-board
> > CONFIG_PPC_SANDPOINT for example that "selects" the various bits you
> > need, and thus the above should depend on it, not EMBEDDED6xx... In fact
> > I'm wondering wether we should kill EMBEDDED6xx :) Unless it's purely a
> > reference to arch/powerpc/platforms/embedded6xx/ as a storage place for
> > board setup_xxx.c files which is useful for platforms that really don't
> > need more than one or 2 files in there.
>
> I have no attachment to "embedded" so I'm happy to see it
> go...especially if I correctly understand what you're saying below.
>
> > > +ifeq ($(CONFIG_EMBEDDED6xx),y)
> > > +src-boot += prom_embedded.c ns16550.c dts/sandpoint.S \
> > > + dt_utils.c sandpoint.c mpc10x.c
> > > +else
> > > +src-boot += prom.c
> > > +endif
> >
> > Again, I think CONFIG_EMBEDDED6xx is the wrong approach. I'd like to
> > avoid the word "embedded" altogether anyway :) Thing is, it would be
> > good if ultimately, embedded boards firmware was capable of passing a
> > device-tree. Thus, embedded a device-tree in the zImage wrapper is more
> > like a "fallback" solution which has the side effect of creating machine
> > specific zImage's.
> >
> > That is why, I think, what we should do is have rules for building
> > separate zImage wrappers. The basic OF one (which exists in both real
> > and virtual mode versions and that I'd like to make capable of also
> > working if a flat device-tree is passed in), the zImage.sandpoint, the
> > zImage.prep, and whatever...
> >
> > Thus enabling CONFIG_PPC_MYBOARD should trigger the build of the
> > board-flavored version of the wrapper in addition to all the other ones
> > for the other boards built as part of a given config.
> >
> > I know it's a bit difficult because the current boot Kbuild rules aren't
> > really design for multiple targets but I think that's the way to go.
>
> Okay, to make sure I understand, you're saying that you want to support a
> .config file having several CONFIG_PPC_BOARD1, CONFIG_PPC_BOARD2,
> CONFIG_PPC_BOARD3 defined at the same time. The resulting zImage would
> run on all 3 boards, right?
>
> I'd be happy with that. It should meet the requirements of both
> the multiplatform and embedded folks. You could combine that with the
> tool paulus talked about a couple weeks ago which would tack the
> appropriate flattened device tree (fdt) onto the zImage after the fact.
>
> http://ozlabs.org/pipermail/linuxppc-dev/2006-April/022435.html
>
> We just need to come up with the tool and make the bootwrapper code
> smart enough to know what dt to use (an OF dt, an fdt from a firmware, a
> fdt tacked on by the tool (along with code to take bd stuff & put it
> into the fdt?)).
>
> All of the boards would likely have to be of the same "class".
> Where "class" would be:
> 1) OF system
> 2) e300 core + PQIIPro (e.g., 83xx)
> 3) e500 core + PQIII (e.g., 85xx)
> 4) 6xx/7xx/74xx + mpc10x (e.g., sandpoint)
> etc. Something like that, anyway--maybe there are only "OF" and
> "non-OF'?
>
> Basically, if its not OF, then its classified by its core + bridge.
>
> So, first thing the zImage does is look for an attached ftb (attached by
> paulus' tool). If its there, use it. If its not there, use either the
> OFDT (for OF class) or expect a dt to be passed in from the firmware (for
> all the other classes). That way you can easily override the dt in the field.
>
> > .../...
> >
> > About the .dts file, we should look into "shipping" a pre-built one so
> > that dtc is not required for building a kernel.
>
> Okay, paulus' tool would allow that. We should also make it smart
> enough to replace an attached dts (really dtb--'b' for 'binary') with
> a new one.
>
> > I think we already have
> > a mecanism for providing "shipped" versions of files and having the
> > option of rebuilding them from source (though I don't have the details
> > in mind at the moment)
>
> I don't know what you're referring to here.
>
> > > diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
> >
> > .../.. io stuffs ...
> >
> > Well... io accessors in here can't harm, the question is more how they
> > are used ;)
> >
> > > +#define PCI_DEVFN(slot,func) ((((slot) & 0x1f) << 3) | ((func) & 0x07))
> > > +
> > > +/* Indirect PCI config space access routines */
> > > +static inline void
> > > +pci_indirect_read_config_byte(u32 *cfg_addr, u32 *cfg_data, int devfn,
> > > + int offset, u8 *val)
> > > +{
> > > + out_be32(cfg_addr,
> > > + ((offset & 0xfc) << 24) | (devfn << 16) | (0 << 8) | 0x80);
> > > + *val = in_8((u8 *)(cfg_data + (offset & 3)));
> > > + return;
> > > +}
> > > +
> > > +static inline void
> > > +pci_indirect_read_config_dword(u32 *cfg_addr, u32 *cfg_data, int devfn,
> > > + int offset, u32 *val)
> > > +{
> > > + out_be32(cfg_addr,
> > > + ((offset & 0xfc) << 24) | (devfn << 16) | (0 << 8) | 0x80);
> > > + *val = in_le32(cfg_data + (offset & 3));
> > > + return;
> > > +}
> >
> > That's more annoying... if we start having PCI config space access in
> > the boot wrapper how far will it stop ? I'd rather keep that sort of
> > stuff local to myboard.c file unless it's really worth sharing... Unless
> > we end up with really common need for them in which case those should be
> > in separate files, possibly in a separate dir (thinking about it, prep
> > will probably need that too)
>
> Sure. I was just grabbing code I needed and sticking it whereever to
> get things to work. If mpc10x.c is the only one that uses those routines
> then they should be in that file only.
>
> > The main problem is how do we do printf kind of things from such a
> > bootloader. That needs IO, thus uart drivers etc... possibly parsing
> > from the device-tree etc... I'm tempted to just have a global
> > "boot_puts" function pointer set by the board and/or OF code to use
> > through the bootloader, maybe a shared uart.c file with various uart
> > bits and keep the gory implementation details of mapping the uart and
> > using those uart bits in the myboard.c file...
>
> Okay.
>
> Question: are we still going to allow cmdline editing in the
> bootwrapper? If so, we also need to get uart input and munge the dtb
> to put the new args back into the /chosen/bootargs field.
>
> > > +#ifdef CONFIG_PPC_OF
> > > typedef void (*kernel_entry_t)( unsigned long,
> > > unsigned long,
> > > void *,
> > > void *);
> > > +#else
> > > +void platform_fixups(void *dt_blob);
> > > +extern void *dt_blob_start;
> > > +extern void *dt_blob_end;
> > > +void edit_cmdline(void *dt_blob_start);
> > > +typedef void (*kernel_entry_t)(void *dtb_addr, void *kernel_entry_paddr,
> > > + void *must_be_null);
> > > +#endif
> >
> > Why 2 different prototypes for kernel_entry ?
>
> One for "OF", one for "non-OF" but I'll change it to
> "typedef void (*kernel_entry_t)(void *addr, ...);"
> to support both. Hrm, I may have another idea... Anyway, I'll do
> something about the #ifdef.
>
> > I think we need something like CONFIG_PPC_BOOT_HAS_BUILTIN_DT that
> > enables various DT related stuff in a clean way and have a builtin_dt.h
> > file with related prototypes & definitions.
>
> If we have the tool mentioned above, we shouldn't need a CONFIG option.
> Just check for a NULL ptr or something like that which indicates there's
> no dtb attached.
>
> > > #undef DEBUG
> > > @@ -218,7 +227,7 @@ void start(unsigned long a1, unsigned lo
> > > if (getprop(chosen_handle, "stdout", &stdout, sizeof(stdout)) != 4)
> > > exit();
> > >
> > > - printf("\n\rzImage starting: loaded at 0x%p (sp: 0x%p)\n\r", _start, sp);
> > > + printf("\n\rzImage starting: loaded at 0x%p (sp: 0x%p)\n\r", _start,sp);
> >
> > Gratuituous uglyfication :)
>
> Again, I was just hacking stuff...
>
> <snip>
>
> > >
> > > /* Eventually gunzip the kernel */
> > > @@ -299,6 +311,7 @@ #endif
> > > flush_cache((void *)vmlinux.addr, vmlinux.size);
> > >
> > > kernel_entry = (kernel_entry_t)vmlinux.addr;
> > > +#ifdef CONFIG_PPC_OF
> > > #ifdef DEBUG
> > > printf( "kernel:\n\r"
> > > " entry addr = 0x%lx\n\r"
> > > @@ -311,9 +324,20 @@ #ifdef DEBUG
> > > #endif
> >
> > > kernel_entry(a1, a2, prom, NULL);
> > > +#else /* !CONFIG_PPC_OF ==> flattened device tree */
> > > +#ifdef DEBUG
> > > + printf("kernel:\n\r"
> > > + " entry addr = 0x%lx\n\r"
> > > + " flattened dt = 0x%lx\n\r",
> > > + (unsigned long)kernel_entry, &dt_blob_start);
> > > +#endif
> > > + edit_cmdline(&dt_blob_start);
> > > + platform_fixups(&dt_blob_start);
> > >
> > > + kernel_entry(&dt_blob_start, (void *)vmlinux.addr, NULL);
> > > +#endif
> >
> > Let's avoid #ifdef's if we can... provide function pointers where it
> > matter setup by the board/OF init code maybe but not ifdef's. Afaik,
> > only WD actually _likes_ ifdef's :)
>
> I'll fix it up.
>
> > > +++ b/arch/powerpc/boot/mpc10x.c
> >
> > We'll need some subdirs here or it will get messy quick...
>
> Yep.
>
> > > diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> >
> > Same comment as above
> >
> > > +/* XXXX Get info from dt instead */
> > > +static struct {
> > > + int baud_base;
> > > + unsigned long com_port;
> > > + u16 iomem_reg_shift;
> > > +} rs_table[RS_TABLE_SIZE] = {
> > > + { BASE_BAUD, SANDPOINT_SERIAL_0, 0 },
> > > + { BASE_BAUD, SANDPOINT_SERIAL_1, 0 },
> > > +};
> >
> > Well, your own comment says it all :) I think we might need an
> > equivalent of prom_parse.c in the bootloader
>
> Yes, this was just a hack to get the sandpoint going.
>
> > +
> > > +/* #ifndef CONFIG_PPC_OF XXXX */
> > > +
> > > +/* Definitions used by the flattened device tree */
> > > +#define OF_DT_HEADER 0xd00dfeed /* marker */
> > > +#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
> > > +#define OF_DT_END_NODE 0x2 /* End node */
> > > +#define OF_DT_PROP 0x3 /* Property: name off, size,
> > > + * content */
> > > +#define OF_DT_NOP 0x4 /* nop */
> > > +#define OF_DT_END 0x9
> > > +
> > > +#define OF_DT_VERSION 0x10
> >
> > .../... (flat DT definitions)
> >
> > Can't we share the kernel definition here ? Maybe split the kenrel one
> > in two if necessary ? I don't like that sort of duplication...
>
> I hope so. I'm hoping we can make a special dir somewhere that has the
> definitions of stuff shared between the bootwrapper & the kernel.
>
> How about arch/powerpc/shared? I dunno, something sensible.
>
> > > +unsigned long serial_init(int chan, void *ignored);
> > > +void serial_putc(unsigned long com_port, unsigned char c);
> > > +unsigned char serial_getc(unsigned long com_port);
> > > +int serial_tstc(unsigned long com_port);
> >
> > Forgot to mention that earlier, but those should be uart_* imho (or even
> > 16550_*) since we'll surely have different species of serial ports to
> > deal with and I don't like name mixup. Unless we consider that only ever
> > one of those serial files get built in a given zImage wrapper in which
> > case it makes some sense...
>
> Okay.
>
> > > +call_prom(const char *service, int nargs, int nret, ...)
> > > +{
> > > +
> > > + static struct {
> > > + char *service;
> > > + int ((*rtn)(int nargs, int nret, va_list args));
> > > + } services[] = {
> > > + { "exit", service_exit },
> > > + { "finddevice", service_finddevice },
> > > + { "getprop", service_getprop },
> > > + /* { "write", service_write }, */
> > > + };
> > > + va_list args;
> > > + int i, rc = 0;
> > > +
> > > + for (i=0; i<ARRAY_SIZE(services); i++)
> > > + if (!strcmp(service, services[i].service)) {
> > > + va_start(args, nret);
> > > + rc = services[i].rtn(nargs, nret, args);
> > > + va_end(args);
> > > + }
> > > +
> > > + return (nret > 0)? rc : 0;
> > > +}
> >
> > I don't think call_prom is the right abstraction :) We have to decide
> > here, we have two choices:
> >
> > - Either a given zImage wrapper can be booted from both a real OF and
> > have an embedded flat DT, in which case we need function pointers and I
> > think the right abstraction is for individual prom functions to have
> > their function pointer rathaer than "multiplex" through call_prom
> >
> > - Or a given zImage wrapper is a single board thingy. That is it is
> > either the OF wrapper _or_ it can contain an embedded DT. Probably
> > easier that way and no need for funciton pointers nor mux at all... I
> > tend to think that might be the right way to go at this point...
> > Especially since as I wrote before, I'm tempted to think we should just
> > in that case build multiple zImage wrappers. The only thing there is
> > that if we go that route, I'd like the "OF" one to also be able to boot
> > with a flat DT passed on entry to it so it will be useable as a generic
> > zImage for firmwares that have a flat DT to pass to the kernel. The only
> > "issue" with that is it might be difficult to have console output unless
> > we do the putc function pointer thing I described earlier and have
> > several "uart" impleentations with differnet names and enough
> > device-tree parsing to be able to instanciate them (almost a copy of
> > kernel's legacy serial stuff). Another option if we want console output
> > is to add something to the DT header specifically for use by such early
> > boot code that specifies a function that can be called back for
> > displaying thing as long as a given memory range isn't overriden (the FW
> > itself)
> >
> > Comments are welcome here, this is I think the most tricky point and
> > where we need to make a decision...
>
> I'm very happy to not use the 'call_prom' abstraction. :)
>
> I guess I have the first one in mind. You have a zImage that runs on
> 1 to n different platforms. The zImage has to determine which DT to use
> (OF DT, fdt from firmware, fdt attached by tool) and pick it apart to
> find the I/O resources and serial driver to use. The CONFIG_<BOARD>'s
> that are defined would determine the drivers that get built in to the zImage.
>
> > > diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> > > index 6e67b5b..2feca55 100644
> > > --- a/arch/powerpc/kernel/legacy_serial.c
> > > +++ b/arch/powerpc/kernel/legacy_serial.c
> > > @@ -147,9 +147,11 @@ static int __init add_legacy_isa_port(st
> > > if (reg == NULL)
> > > return -1;
> > >
> > > +#if 0 /* XXXX */
> > > /* Verify it's an IO port, we don't support anything else */
> > > if (!(reg[0] & 0x00000001))
> > > return -1;
> > > +#endif
> >
> > Gack ? Care to explain ?
>
> This 'if' always executed and threw me into the weeds. I didn't get
> back to really figuring it out. This was a hack to get going.
>
> > > +obj-$(CONFIG_EMBEDDED6xx) += embedded6xx/
> >
> > Hrmph.... (random noises)
>
> ? No, I needed that to get the build to go into platforms/embedded6xx.
> Since platforms/embedded6xx was already there, I assumed that was where
> I was to put things like the sandpoint. If/when we get rid of
> "embedded", I'll move it to whereever it should go then.
>
> > > +/*
> > > + * Define all of the IRQ senses and polarities. Taken from the
> > > + * Sandpoint X3 User's manual.
> > > + */
> > > +static u_char sandpoint_openpic_initsenses[] __initdata = {
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 0: SIOINT */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 1: XXXX FILL?? */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 2: PCI Slot 1 */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 3: PCI Slot 2 */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 4: PCI Slot 3 */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 5: PCI Slot 4 */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 6: XXXX FILL?? */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 7: XXXX FILL?? */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 8: IDE (INT C) */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 9: IDE (INT D) */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 10: */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 11: */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 12: */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 13: */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 14: */
> > > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 15: */
> > > +};
> >
> > Of course you already know that this has to go into the device-tree :)
>
> Yeah, I guess it should. I'll have to figure out how to do that.
>
> > > +/*
> > > + * Interrupt setup and service. Interrrupts on the Sandpoint come
> > > + * from the four PCI slots plus the 8259 in the Winbond Super I/O (SIO).
> > > + * The 8259 is cascaded from EPIC IRQ0, IRQ1-4 map to PCI slots 1-4,
> > > + * IDE is on EPIC 7 and 8.
> > > + */
> > > +static void __init
> > > +sandpoint_init_IRQ(void)
> > > +{
> > > + struct mpic *mpic;
> > > + phys_addr_t openpic_paddr = 0xfc000000 + /* XXXX */
> > > + MPC10X_EUMB_EPIC_OFFSET;
> > > +
> > > + /* This doesn't handle i2c, dma, i2o, or timer intrs right now XXXX */
> > > + mpic = mpic_alloc(openpic_paddr, MPIC_PRIMARY,
> > > + 16 /* XXXX otherwise num_sources used */ ,
> > > + NUM_8259_INTERRUPTS,
> > > + 0, /* was 16 */
> > > + NR_IRQS - 4 /* XXXX */,
> > > + sandpoint_openpic_initsenses,
> > > + sizeof(sandpoint_openpic_initsenses), " EPIC ");
> > > +
> > > + BUG_ON(mpic == NULL); /* XXXX */
> > > + mpic_assign_isu(mpic, 0, openpic_paddr + 0x10200);
> > > + mpic_init(mpic);
> > > + mpic_setup_cascade(NUM_8259_INTERRUPTS, i8259_irq_cascade, NULL);
> > > + i8259_init(0xfef00000, 0); /* pci iack addr */
> > > +}
> >
> > It would be really nice if we could define properties to put in the
> > "mpic" node that defines the various attributes to pass to it and that
> > sort of thing so that we can have a generic "mpic_init_IRQ" that walks
> > all MPICs and instanciate & link them in cascade when necessary... Oh
> > well, food for thought, no high priority there.
>
> That would be great to have!
>
> > > +/*
> > > + * Freescale Sandpoint interrupt routing.
> > > + */
> > > +static inline int
> > > +x3_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
> > > + */
> > > + {
> > > + { 16, 0, 0, 0 }, /* IDSEL 11 - i8259 on Winbond */
> > > + { 0, 0, 0, 0 }, /* IDSEL 12 - unused */
> > > + { 18, 21, 20, 19 }, /* IDSEL 13 - PCI slot 1 */
> > > + { 19, 18, 21, 20 }, /* IDSEL 14 - PCI slot 2 */
> > > + { 20, 19, 18, 21 }, /* IDSEL 15 - PCI slot 3 */
> > > + { 21, 20, 19, 18 }, /* IDSEL 16 - PCI slot 4 */
> > > + };
> > > +
> > > + const long min_idsel = 11, max_idsel = 16, irqs_per_slot = 4;
> > > + return PCI_IRQ_TABLE_LOOKUP;
> > > +}
> >
> > Of course you also know that the above has to go into the device-tree as
> > well :)
>
> Okay... :)
>
> > > +static void __init
> > > +sandpoint_setup_winbond_83553(struct pci_controller *hose)
> > > +{
> > > + int devfn;
> > > +
> > > + /*
> > > + * Route IDE interrupts directly to the 8259's IRQ 14 & 15.
> > > + * We can't route the IDE interrupt to PCI INTC# or INTD# because those
> > > + * woule interfere with the PMC's INTC# and INTD# lines.
> > > + */
> > > + /*
> > > + * Winbond Fcn 0
> > > + */
> > > + devfn = PCI_DEVFN(11,0);
> > > +
> > > + early_write_config_byte(hose,
> > > + 0,
> > > + devfn,
> > > + 0x43, /* IDE Interrupt Routing Control */
> > > + 0xef);
> > > + early_write_config_word(hose,
> > > + 0,
> > > + devfn,
> > > + 0x44, /* PCI Interrupt Routing Control */
> > > + 0x0000);
> > > +
> > > + /* Want ISA memory cycles to be forwarded to PCI bus */
> > > + early_write_config_byte(hose,
> > > + 0,
> > > + devfn,
> > > + 0x48, /* ISA-to-PCI Addr Decoder Control */
> > > + 0xf0);
> > > +
> > > + /* Enable Port 92. */
> > > + early_write_config_byte(hose,
> > > + 0,
> > > + devfn,
> > > + 0x4e, /* AT System Control Register */
> > > + 0x06);
> > > + /*
> > > + * Winbond Fcn 1
> > > + */
> > > + devfn = PCI_DEVFN(11,1);
> > > +
> > > + /* Put IDE controller into native mode. */
> > > + early_write_config_byte(hose,
> > > + 0,
> > > + devfn,
> > > + 0x09, /* Programming interface Register */
> > > + 0x8f);
> > > +
> > > + /* Init IRQ routing, enable both ports, disable fast 16 */
> > > + early_write_config_dword(hose,
> > > + 0,
> > > + devfn,
> > > + 0x40, /* IDE Control/Status Register */
> > > + 0x00ff0011);
> > > + return;
> > > +}
> >
> > How much of the above could/should be done by the wrapper since it does
> > config space access hacks ? My idea is that we might be able to remove
> > pretty much _everything_ from this sandpoint.c file ... My dream would
> > be to have a generic board support that matches a list of known boards
> > for which no special code is needed, only the device-tree (and possibly
> > the zImage wrapper).
>
> That's a good dream. :)
>
> > The main things preventing us from doing that at the moment is that we
> > need to define enough standard nodes/properties to have the ability to
> > the setup interrupt controller tree entirely from it, and the PCI host
> > bridges as well. For the later, that means encoding enough of the bridge
> > type and config access method to allow having a generic device-tree
> > based piece of code that does what add_bridges() does in a generic way.
>
> Yep.
>
> > > +static int
> > > +x3_exclude_device(u_char bus, u_char devfn)
> > > +{
> > > + if ((bus == 0) && (PCI_SLOT(devfn) == 0))
> > > + return PCIBIOS_DEVICE_NOT_FOUND;
> > > + else
> > > + return PCIBIOS_SUCCESSFUL;
> > > +}
> >
> > If we need to exclude devices in a generic way, we could define a
> > specific exclude list property... or use what I think has already been
> > defined by OF for indicating which slots should be probed :)
>
> I'll try to do it through pci quirks, if I can. If not, then I agree.
>
> > > +static int __init
> > > +add_bridge(struct device_node *dev)
> > > +{
> > > + int len;
> > > + struct pci_controller *hose;
> > > + int *bus_range;
> > > +
> > > + printk("Adding PCI host bridge %s\n", dev->full_name);
> > > +
> > > + bus_range = (int *) get_property(dev, "bus-range", &len);
> > > + if (bus_range == NULL || len < 2 * sizeof(int))
> > > + printk(KERN_WARNING "Can't get bus-range for %s, assume"
> > > + " bus 0\n", dev->full_name);
> > > +
> > > + hose = pcibios_alloc_controller();
> > > + if (hose == NULL)
> > > + return -ENOMEM;
> > > + hose->first_busno = bus_range ? bus_range[0] : 0;
> > > + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> > > + setup_indirect_pci(hose, 0xfec00000, 0xfee00000);
> > > +
> > > + /* Interpret the "ranges" property */
> > > + /* This also maps the I/O region and sets isa_io/mem_base */
> > > + pci_process_bridge_OF_ranges(hose, dev, 1);
> > > +
> > > + return 0;
> > > +}
> >
> > See above comments.... Looks ok but how many boards will end up having
> > very small variations of that same code and thus can we find a way to
> > make that totally generic...
>
> Many...
>
> > > +u32 mag_dbg = 0;
> > > +
> > > +static void __init
> > > +sandpoint_setup_arch(void)
> > > +{
> > > + loops_per_jiffy = 100000000 / HZ;
> > > + isa_io_base = 0xfe000000;
> > > + isa_mem_base = 0x80000000;
> > > + pci_dram_offset = 0;
> >
> > The isa stuff should probably be deduced from the device-tree, the
> > default LPJ too, probably not even useful anymore since we are using the
> > timebase nowadays.
>
> Okay.
>
> > > +#ifdef CONFIG_BLK_DEV_INITRD
> > > + if (initrd_start)
> > > + ROOT_DEV = Root_RAM0;
> > > + else
> > > +#endif
> > > +#ifdef CONFIG_ROOT_NFS
> > > + ROOT_DEV = Root_NFS;
> > > +#else
> > > + ROOT_DEV = Root_HDA1;
> > > +#endif
> >
> > Same comment as above, this is fairly generic and we could even imagine
> > something like a linux,default-boot-device thing in the DT...
>
> OK.
>
> > > +#if 1 /* XXXX NEW */
> > > + {
> > > + struct device_node *np;
> > > +
> > > + mag_dbg = 1;
> > > + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> > > + add_bridge(np);
> > > + mag_dbg = 0;
> > > +
> > > + ppc_md.pci_swizzle = common_swizzle;
> > > + ppc_md.pci_map_irq = x3_map_irq;
> > > + ppc_md.pci_exclude_device = x3_exclude_device; /* XXXX */
> > > + }
> > > +#endif
> >
> > The problem of IRQ mapping & swizzling will be solved real soon
> > (hopefully early 2.6.18) so that we can completely rely on the
> > device-tree without needing device_node's for every PCI device. Only P2P
> > bridges that don't do standard swizzling (typically bridges soldered on
> > the motherboard) will require device nodes. I'm working on it :)
> >
> > The idea is that the host bridge will need the standard interrupt-map &
> > interrupt-map-mask which will indicate the interrupt mapping for every
> > line of every slot/device in the standard way handled by OF (that
> > already works). And I'll add code that will be able to handle PCI
> > devices without a node by artificially building their "interrupts"
> > property based on the interrupt pin config space entry and walking up
> > the PCI tree, doing standard swizzling when encountering a P2P bridge
> > until we hit something with a device-node in which case we hook our
> > result to the interrupt-map of that device-node.
>
> Cool. I'll keep an eye out for that.
>
> > > + if (cpu_has_feature(CPU_FTR_SPEC7450))
> > > + /* 745x is different. We only want to pass along enable. */
> > > + _set_L2CR(L2CR_L2E);
> > > + else if (cpu_has_feature(CPU_FTR_L2CR))
> > > + /* All modules have 1MB of L2. We also assume that an
> > > + * L2 divisor of 3 will work.
> > > + */
> > > + _set_L2CR(L2CR_L2E | L2CR_L2SIZ_1MB | L2CR_L2CLK_DIV3
> > > + | L2CR_L2RAM_PIPE | L2CR_L2OH_1_0 | L2CR_L2DF);
> >
> > Keeping in mind my idea of having as much generic code as possible,
> > whould we do the above in the boot wrapper or if not, should we provide
> > some DT entries indicating that L2CR should be reset and to which
> > values ?
>
> I vote for a DT entry.
>
> > > +#if 0
> > > + /* Untested right now. */
> > > + if (cpu_has_feature(CPU_FTR_L3CR)) {
> > > + /* Magic value. */
> > > + _set_L3CR(0x8f032000);
> > > + }
> > > +#endif
> > > +}
> >
> > Same comment as above but for L3CR
>
> DT entry. :)
>
> > .../...
> >
> > > +/*
> > > + * Fix IDE interrupts.
> > > + */
> > > +static int __init
> > > +sandpoint_fix_winbond_83553(void)
> > > +{
> > > + /* Make some 8259 interrupt level sensitive */
> > > + outb(0xe0, 0x4d0);
> > > + outb(0xde, 0x4d1);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +arch_initcall(sandpoint_fix_winbond_83553);
> > > +
> > > +/*
> > > + * Initialize the ISA devices on the Nat'l PC87308VUL SuperIO chip.
> > > + */
> > > +static int __init
> > > +sandpoint_setup_natl_87308(void)
> > > +{
> > > + u_char reg;
> > > +
> > > + /*
> > > + * Enable all the devices on the Super I/O chip.
> > > + */
> > > + SANDPOINT_87308_SELECT_DEV(0x00); /* Select kbd logical device */
> > > + SANDPOINT_87308_CFG_OUTB(0xf0, 0x00); /* Set KBC clock to 8 Mhz */
> > > + SANDPOINT_87308_DEV_ENABLE(0x00); /* Enable keyboard */
> > > + SANDPOINT_87308_DEV_ENABLE(0x01); /* Enable mouse */
> > > + SANDPOINT_87308_DEV_ENABLE(0x02); /* Enable rtc */
> > > + SANDPOINT_87308_DEV_ENABLE(0x03); /* Enable fdc (floppy) */
> > > + SANDPOINT_87308_DEV_ENABLE(0x04); /* Enable parallel */
> > > + SANDPOINT_87308_DEV_ENABLE(0x05); /* Enable UART 2 */
> > > + SANDPOINT_87308_CFG_OUTB(0xf0, 0x82); /* Enable bank select regs */
> > > + SANDPOINT_87308_DEV_ENABLE(0x06); /* Enable UART 1 */
> > > + SANDPOINT_87308_CFG_OUTB(0xf0, 0x82); /* Enable bank select regs */
> > > +
> > > + /* Set up floppy in PS/2 mode */
> > > + outb(0x09, SIO_CONFIG_RA);
> > > + reg = inb(SIO_CONFIG_RD);
> > > + reg = (reg & 0x3F) | 0x40;
> > > + outb(reg, SIO_CONFIG_RD);
> > > + outb(reg, SIO_CONFIG_RD); /* Have to write twice to change! */
> > > +
> > > + return 0;
> > > +}
> >
> > Looks like zImage wrapper work to me... Unless we ever get booted by a
> > firmware that both provides a flat DT and doesn't do the above....
> >
> > Ok, I'm not _ABSOLUTELY_ trying to remove the need for a myboar.c file
> > here ... but it might be worth doing something generic enough so that
> > it's either reduced to the strict minimum in many cases _or_ made
> > completely unnecessary if we can...
>
> OK
>
> > > +arch_initcall(sandpoint_setup_natl_87308);
> > > +
> > > +static int __init
> > > +sandpoint_request_io(void)
> > > +{
> > > + request_region(0x00,0x20,"dma1");
> > > + request_region(0x20,0x20,"pic1");
> > > + request_region(0x40,0x20,"timer");
> > > + request_region(0x80,0x10,"dma page reg");
> > > + request_region(0xa0,0x20,"pic2");
> > > + request_region(0xc0,0x20,"dma2");
> > > +
> > > + return 0;
> > > +}
> >
> > The above has to go... not sure yet what is the best way but it's just a
> > pain... Could be made dependent on the OFDT too
>
> OK
>
> > > +arch_initcall(sandpoint_request_io);
> > > +#endif
> > > +
> > > +static void __init
> > > +sandpoint_map_io(void)
> > > +{
> > > + io_block_mapping(0xfe000000, 0xfe000000, 0x02000000, _PAGE_IO);
> > > +}
> >
> > To kill absolutely. What is it there for ? At the very least, make
> > io_block_mapping allocate virtual space as discussed earlier. I'd like
> > to keep BATs for RAM anyway
>
> It'll go away eventually.
>
> > > +static void
> > > +sandpoint_restart(char *cmd)
> > > +{
> > > + local_irq_disable();
> > > +
> > > + /* Set exception prefix high - to the firmware */
> > > + _nmask_and_or_msr(0, MSR_IP);
> > > +
> > > + /* Reset system via Port 92 */
> > > + outb(0x00, 0x92);
> > > + outb(0x01, 0x92);
> > > +
> > > + for(;;); /* Spin until reset happens */
> > > +}
> >
> > The above is fairly common. (Or variations of it). In the context of a
> > "generic" board, we could imagine having a list of known "reboot
> > methods" and have a DT node indicating which one to use...
>
> Yep.
>
> > > +static void
> > > +sandpoint_power_off(void)
> > > +{
> > > + local_irq_disable();
> > > + for(;;); /* No way to shut power off with software */
> > > + /* NOTREACHED */
> > > +}
> >
> > The above is _VERY_ commmon :) probably worth just not having a callback
> > in ppc_md. at all...
> >
> > > +static void
> > > +sandpoint_halt(void)
> > > +{
> > > + sandpoint_power_off();
> > > + /* NOTREACHED */
> > > +}
> >
> > Same comment as before.
>
> I do see a couple in arch/ppc/platforms that do something different so
> how about keeping ppc_md.power_off/_halt but making the above the default
> (with only 1 implementation) which can be changed by board code?
>
> > > +static void
> > > +sandpoint_show_cpuinfo(struct seq_file *m)
> > > +{
> > > + seq_printf(m, "vendor\t\t: Freescale\n");
> > > + seq_printf(m, "machine\t\t: Sandpoint\n");
> > > +}
> >
> > Do we need that ? We could define standard DT properties that get
> > printed in cpuinfo and have that in setup-common.c ...
>
> That would be better.
>
> > .../... (commented out IDE code)
> >
> > This is a windbond ? Can't it just be probed/detected using normal PCI
> > probing ?
>
> I have to revisit all of the IDE stuff in that file and figure out
> what's really needed (if any). That's why I have it all '#if 0' right
> now. I will get to it eventually.
>
> > > +
> > > +/*
> > > + * Set BAT 3 to map 0xf8000000 to end of physical memory space 1-to-1.
> > > + */
> > > +static __inline__ void
> > > +sandpoint_set_bat(void)
> > > +{
> > > + unsigned long bat3u, bat3l;
> > > +
> > > + __asm__ __volatile__(
> > > + " lis %0,0xf800\n \
> > > + ori %1,%0,0x002a\n \
> > > + ori %0,%0,0x0ffe\n \
> > > + mtspr 0x21e,%0\n \
> > > + mtspr 0x21f,%1\n \
> > > + isync\n \
> > > + sync "
> > > + : "=r" (bat3u), "=r" (bat3l));
> > > +}
> >
> > WTF ?
>
> It'll disappear. The sandpoint.c is copied from arch/ppc and hacked.
> Its pretty old so there's lots of code that can probably be weeded out.
>
> > > +TODC_ALLOC();
> > > +
> > > +static int __init
> > > +sandpoint_probe(void)
> > > +{
> > > + return 1;
> > > +}
> >
> > WTF (bis) ? :)
>
> bis?
>
> Its just a hack to get it going.
>
> > > +define_machine(sandpoint) {
> > > + .name = "Sandpoint",
> > > + .probe = sandpoint_probe,
> > > + .setup_arch = sandpoint_setup_arch,
> > > + .setup_io_mappings = sandpoint_map_io,
> > > + .init_IRQ = sandpoint_init_IRQ,
> > > + .show_cpuinfo = sandpoint_show_cpuinfo,
> > > + .get_irq = mpic_get_irq,
> > > + .restart = sandpoint_restart,
> > > + .power_off = sandpoint_power_off,
> > > + .halt = sandpoint_halt,
> > > + .calibrate_decr = generic_calibrate_decr,
> > > + /*
> > > + .progress = udbg_progress,
> > > + */
> > > +};
> >
> > So on the TODO list, replace as much as we can of the above with
> > generic_* equivalents until nothing remains :)
>
> Yep, that's the goal.
>
> > > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > > index 7dcdfcb..1badbec 100644
> > > --- a/arch/powerpc/sysdev/mpic.c
> > > +++ b/arch/powerpc/sysdev/mpic.c
> > > @@ -629,6 +629,13 @@ #endif /* CONFIG_SMP */
> > > mb();
> > > }
> > >
> > > +#ifdef CONFIG_MPIC_SERIAL
> > > + /* For serial interrupts & set clock ratio */
> > > + mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1,
> > > + mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1)
> > > + | (1<<27) | (0x7<<28));
> > > +#endif
> >
> > This should not be an #ifdef.... this should be an MPIC init flag passed
> > when initializing it. (and if we do generic device-tree instanciation of
> > PIC's, we could define standard properties to put in the MPIC node to
> > enable those flags).
>
> Okay, I'll move it into the dt.
>
> > Keep up the good work ! :)
>
> Heh.
>
> > Cheers,
> > Ben.
>
> Thanks for the comments.
>
> Mark
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-19 20:09 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <44B7857A.2060101@freescale.com>
On Jul 14, 2006, at 6:52 AM, Li Yang wrote:
> This adds USB platform support to MPC8349 PB. It works with the
> fsl_usb2_udc driver.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
>
> arch/powerpc/platforms/83xx/Kconfig | 4 ++
> arch/powerpc/platforms/83xx/mpc834x_sys.c | 72 +++++++++++++++++++
> ++++++++++
> arch/powerpc/platforms/83xx/mpc834x_sys.h | 24 ++++++++++
> 3 files changed, 113 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
> platforms/83xx/Kconfig
> index 7675e67..8404cdf 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -24,4 +31,14 @@ config MPC834x
> select PPC_INDIRECT_PCI
> default y if MPC834x_SYS
>
> +config 834x_USB_SUPPORT
> + bool
> + default y if MPC834x_SYS && (USB || USB_GADGET)
> +
> endmenu
I dont think we need this, we should be able to use the USB, and 834x
CONFIG options in the code.
> diff --git a/arch/powerpc/platforms/83xx/mpc834x_sys.c b/arch/
> powerpc/platforms/83xx/mpc834x_sys.c
> index 7e789d2..f10d4ae 100644
> --- a/arch/powerpc/platforms/83xx/mpc834x_sys.c
> +++ b/arch/powerpc/platforms/83xx/mpc834x_sys.c
> @@ -36,6 +36,7 @@ #include <asm/irq.h>
> #include <asm/prom.h>
> #include <asm/udbg.h>
> #include <sysdev/fsl_soc.h>
> +#include <linux/fsl_devices.h>
> #include "mpc83xx.h"
> @@ -71,6 +72,72 @@ mpc83xx_map_irq(struct pci_dev *dev, uns
> }
> #endif /* CONFIG_PCI */
> +#ifdef CONFIG_834x_USB_SUPPORT
Just make it dependent on CONFIG_USB_EHCI_HCD or something like that.
> +void mpc834x_usb_board_cfg(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);
> +}
> +
> +/* Note: This is only for PB, not for PB+PIB
> + * On PB only port0 is connected using ULPI */
> +static int mpc834x_usb_cfg(void)
> +{
> + unsigned long sccr, sicrl;
> + volatile unsigned long *p;
> + unsigned long __iomem *immap;
> + struct device_node *np = NULL;
> + int port0_is_dr = 0;
> +
> + if ((np = of_find_compatible_node(np, "usb", "fsl-usb2-dr")) !=
> NULL)
> + port0_is_dr = 1;
> + if ((np = of_find_compatible_node(np, "usb", "fsl-usb2-mph")) !=
> NULL){
> + if (port0_is_dr) {
> + printk(KERN_WARNING
> + "There is only one USB port on PB board! \n");
> + return -1;
> + } else if (!port0_is_dr)
> + /* No usb port enabled */
> + return -1;
> + }
> +
> + immap = ioremap(get_immrbase(), 0x100000);
> +
> + /* Configure clock */
> + p = (volatile unsigned long *)((u32)immap + MPC83XX_SCCR_OFFS);
> + sccr = *p;
> + if (port0_is_dr)
> + sccr |= MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
> + else
> + sccr |= MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
> + *p = sccr;
This really needs to take into account the platform frequency. I
guess technically, at 1:3 we will always be below the max 133Mhz.
> +
> + /* Configure Pin */
> + p = (volatile unsigned long *)((u32)immap + MPC83XX_SICRL_OFFS);
> + sicrl = *p;
> + /* set port0 only */
> + if (port0_is_dr) + sicrl |= MPC83XX_SICRL_USB0;
> + else + sicrl &= ~(MPC83XX_SICRL_USB0);
> + *p = sicrl;
> +
Why dont we just do all this in fsl_usb_of_init
> + iounmap(immap);
> + return 0;
> +}
> +
> +#endif /* CONFIG_834x_USB_SUPPORT */
> +
> /*
> **********************************************************************
> **
> *
> * Setup the architecture
> @@ -102,6 +169,11 @@ #ifdef CONFIG_PCI
> ppc_md.pci_exclude_device = mpc83xx_exclude_device;
> #endif
> +#ifdef CONFIG_834x_USB_SUPPORT
> + mpc834x_usb_cfg();
> + mpc834x_usb_board_cfg();
> +#endif
> +
> #ifdef CONFIG_ROOT_NFS
> ROOT_DEV = Root_NFS;
> #else
> diff --git a/arch/powerpc/platforms/83xx/mpc834x_sys.h b/arch/
> powerpc/platforms/83xx/mpc834x_sys.h
> index fedecb7..30e45e8 100644
> --- a/arch/powerpc/platforms/83xx/mpc834x_sys.h
> +++ b/arch/powerpc/platforms/83xx/mpc834x_sys.h
> @@ -20,4 +20,28 @@ #define PIRQB MPC83xx_IRQ_EXT5
> #define PIRQC MPC83xx_IRQ_EXT6
> #define PIRQD MPC83xx_IRQ_EXT7
> +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> +#define BCSR_SIZE ((uint)(32 * 1024))
> + +#define BCSR5_OFF 0x05
> +#define BCSR5_INT_USB 0x02
> +
> +#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_USB0 0x40000000
> +#define MPC83XX_SICRL_USB1 0x20000000
> +
> +/* system i/o configuration register high */
> +#define MPC83XX_SICRH_OFFS 0x118
> +#define MPC83XX_SICRH_USB_UTMI 0x00020000
Are these really generic to all MPC83XX? We should move these to
include something like asm-ppc/mpc83xx.h
> +
> +
> #endif /* __MACH_MPC83XX_SYS_H__ */
- kumar
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Timur Tabi @ 2006-07-19 20:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1153166894.4459.4.camel@basalt.austin.ibm.com>
Hollis Blanchard wrote:
> Seems to me that it's far better to have init code in the kernel than
> firmware. For one example, look at the x86 video card init problem
> PowerPC Linux has. It's also far easier to fix/deploy Linux code than
> firmware code, as Li observed, and on top of that it's less work for
> non-UBoot firmwares in the future.
I also agree 100%. The boot loader should only be required to initialize whatever hardware it uses. The kernel should be required to initialize whatever hardware it supports. The kernel should not assume that USB or PCI or whatever has already been initialized by the boot loader. This doesn't happen on x86, so we should it happen on PPC?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Marc Leeman @ 2006-07-19 20:19 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <1E6652B1-3126-4B69-BE9D-8DCE8DCACE7C@embeddedalley.com>
[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]
> I agree. The customers of board ports I've done over the years
> are always eager to get these into the public sources. It just
> seems we run out of time during the pressure of trying to get
> the products done, and they just issue them on CDs or for
> download afterward.
For our boards, I am somewhat more eager to get our port in U-Boot than
in the Linux kernel for a number of reasons.
First; it is always interesting to see how other ppl handle simular
problems during boot up.
Secondly; U-Boot is used to set configuration options at bootup, e.g.
for multi purpose pins. Having your changes (to registers), fixes or
silicon bugs might help ppl and avoid them to look for a silicon bug
workaround.
If I submit a port of our board to U-Boot, clearly comment the changes
(e.g. enable GPIO on pin X while setting registers); I hope that some
ppl can use it. Next to this, Wolfgang is doing a *very* good job of
keeping his tree clean and giving good pointers to problems and clean up
strategies that serve us all.
Having my changes for our boards that are very specific since they are
connected to FPGAs would IMHO serve little purpose in the Linux kernel:
there is very limited access to the hardware and it would only serve to
clutter the kernel with an exponentionally growing number of ports that
most ppl will never use. I think (even though using ARCH and
CROSS_COMPILE during compilation limits the audience); the target
audience between U-Boot and the Linux kernel is slightly different.
Though I do agree that there is a gap: it would be nice to have some
place to submit the kernel patches; possibly not included in the main
tree; just to see how other ppl are tackling the same problem and
avoiding re-doing the same work for the nth time (e.g. writing some
communciation protocol where there are a number of references of ppl
haveing done them, but no real code).
--
greetz, marc
Aeryn died so you could live John. She would want you to keep fighting.
D'Argo - Season of Death
scorpius.homelinux.org 2.6.17 #2 PREEMPT Thu Jun 22 07:18:33 CEST 2006 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-19 20:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <44BE9268.9040806@freescale.com>
On Jul 19, 2006, at 3:13 PM, Timur Tabi wrote:
> Hollis Blanchard wrote:
>
>> Seems to me that it's far better to have init code in the kernel than
>> firmware. For one example, look at the x86 video card init problem
>> PowerPC Linux has. It's also far easier to fix/deploy Linux code than
>> firmware code, as Li observed, and on top of that it's less work for
>> non-UBoot firmwares in the future.
>
> I also agree 100%. The boot loader should only be required to
> initialize whatever hardware it uses. The kernel should be
> required to initialize whatever hardware it supports. The kernel
> should not assume that USB or PCI or whatever has already been
> initialized by the boot loader. This doesn't happen on x86, so we
> should it happen on PPC?
Let's not drag what x86 does as a good or bad example of anything :)
- k
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-19 20:55 UTC (permalink / raw)
To: Marc Leeman; +Cc: linuxppc-dev
In-Reply-To: <20060719201941.GW5219@scorpius.homelinux.org>
[snip]
> Having my changes for our boards that are very specific since they are
> connected to FPGAs would IMHO serve little purpose in the Linux
> kernel:
> there is very limited access to the hardware and it would only
> serve to
> clutter the kernel with an exponentionally growing number of ports
> that
> most ppl will never use. I think (even though using ARCH and
> CROSS_COMPILE during compilation limits the audience); the target
> audience between U-Boot and the Linux kernel is slightly different.
>
> Though I do agree that there is a gap: it would be nice to have some
> place to submit the kernel patches; possibly not included in the main
> tree; just to see how other ppl are tackling the same problem and
> avoiding re-doing the same work for the nth time (e.g. writing some
> communciation protocol where there are a number of references of ppl
> haveing done them, but no real code).
This should be the kernel. The general rule of thumb I've used is if
its useful to more than one other person its worth trying to get into
the kernel. However, I can see if you are doing a one off kernel for
your embedded product that getting your changes into the kernel
wouldn't be worth while. You have to have a desire to interact with
the community if you want to get your code in.
Personally, I see it useful if for no other reason that someone will
fixup my board port if/when they change something which will make my
moving to a newer kernel release that much easier.
- k
^ permalink raw reply
* Re: export-objs in spi Makefile broke in latest linuxppc_2_4_devel [r eposted]?
From: Kumar Gala @ 2006-07-19 21:16 UTC (permalink / raw)
To: Rowan, Chad; +Cc: linuxppc-embedded
In-Reply-To: <86EC6E02268B3D4BA41C1B0C61FB14E60B3C8335@mdcexc01.na.ops.local>
On Jul 19, 2006, at 2:13 PM, Rowan, Chad wrote:
> Shouldn't export-objs in drivers/spi be:
>
> export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5xxx-psc.o \
> spi-iti5200.o spi-eval.o
>
> instead of:
>
> export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5200psc.o \
> spi-iti5200.o spi-eval.o
>
> I believe the spi-algo-mpc5200psc.o should be spi-algo-mpc5xxx-psc.o,
> correct?
Are you really serious about linuxppc_2_4_devel? I can't believe
linuxppc_2_4_devel has changed in months (if not over a year).
- k
^ permalink raw reply
* RE: export-objs in spi Makefile broke in latest linuxppc_2_4_deve l [r eposted]?
From: Rowan, Chad @ 2006-07-19 22:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
linuxppc_2_4_devel is alive and well.
http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=shortlog
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Wednesday, July 19, 2006 4:17 PM
To: Rowan, Chad
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: export-objs in spi Makefile broke in latest linuxppc_2_4_devel
[r eposted]?
On Jul 19, 2006, at 2:13 PM, Rowan, Chad wrote:
> Shouldn't export-objs in drivers/spi be:
>
> export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5xxx-psc.o \
> spi-iti5200.o spi-eval.o
>
> instead of:
>
> export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5200psc.o \
> spi-iti5200.o spi-eval.o
>
> I believe the spi-algo-mpc5200psc.o should be spi-algo-mpc5xxx-psc.o,
> correct?
Are you really serious about linuxppc_2_4_devel? I can't believe
linuxppc_2_4_devel has changed in months (if not over a year).
- k
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Mark A. Greer @ 2006-07-19 22:10 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0607192144310.6432@poirot.grange>
Hi Guennadi,
On Wed, Jul 19, 2006 at 10:02:01PM +0200, Guennadi Liakhovetski wrote:
> Mark, Ben,
>
> On Mon, 22 May 2006, Mark A. Greer wrote:
>
> > Thanks for your time, Ben. Sorry for taking so long to get back to you.
>
> don't have much to comment to specific points, but quoting the entire
> discussion below in case you'll want to further add to it.
Ben and I have talked a little bit privately and the ball is in my court
to produce a set of patches. To that end, I have them ready so expect to
see them shortly.
> What's the status of this work? Mark, have you been further working on
> your port?
Patches to come...
> I'd like to integrate kurobox/linkstation support with
> sandpoint (also 8241). I think, it would be very interesting as it would
> allow us to develop / test the "universal" kernel idea, and at the same
> time explore the limits of board-specific support. Kurobox have a couple
> of very nice "specialities", like a serially attached AVR acting as a
> power-manager, thus requiring __special__ halt and reboot callbacks (so,
> please, Ben, don't remove them).
>
> Any progress with fdt-parsing library for the wrapper / kernel and with
> replacing hard-coded constants and tables with dt-entries?
No real progress with making a library because even though a lot of
functionality is duplicated, most of the kernel code does it on an
internal representation of the fdt and not on the actual fdt. The
bootwrapper code needs to work directly on the fdt so I didn't bother
library-izing it. Once the dust settles, we can library-ize the duplicate
code but for now, its all in arch/powerpc/boot/fdt.c (in my upcoming patches).
> I'd love to discuss the stuff and come to an acceptable design / APIs.
Me too. :)
Mark
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-07-19 22:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060719033618.GA3944@monkey.ibm.com>
On Tue, Jul 18, 2006 at 08:36:18PM -0700, Mike Kravetz wrote:
> > My other comment is this: wouldn't it actually turn out simpler if we
> > read the timebase (and PURR, if we really want to do that too) in the
> > assembly code that implements plpar_hcall_*?
>
> I'll give that a try. My assembly skills are a bit rusty, so it may
> take a little longer to produce something.
Getting the timebase and PURR in assembly is easy enough. So, I thought
about updating the per-cpu statistics while in there. But, I couldn't
find any other assembly code that does this. Sure there is asm code that
updated fields in the PACA, but none that messes with paca.data_offset
(that I could find).
Should the statistic updates also be done in the assembly routines? Or,
how about a call out to a C routine for this?
--
Mike
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Guennadi Liakhovetski @ 2006-07-19 22:29 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719221019.GA32203@mag.az.mvista.com>
On Wed, 19 Jul 2006, Mark A. Greer wrote:
>
> Ben and I have talked a little bit privately and the ball is in my court
> to produce a set of patches. To that end, I have them ready so expect to
> see them shortly.
Great! So, I can really relax and enjoy my holiday next week in beautiful
Eifel:-) And as your patches arrive we'll see how best to integrate
kurobox with them.
One question so far. Looking at your sandpoint.dts pci map:
ranges = <80000000 80000000 70000000 /* pci mem space */
fc000000 fc000000 00100000 /* EUMB */
fe000000 fe000000 00c00000 /* pci i/o space */
fec00000 fec00000 00300000 /* pci cfg regs */
fef00000 fef00000 00100000>; /* pci iack */
I can match hardware addresses against defines in
include/asm-ppc/mpc10x.h, but virtual one - is the map above just an
example and anyway-not-used, or is it a new mapping, or am I missing
something and it has always been like that (1-to-1)? At least this comment
* MAP B (CHRP Map)
* Processor: 0xfe000000 - 0xfebfffff -> PCI I/O: 0x00000000 - 0x00bfffff
* Processor: 0x80000000 - 0xbfffffff -> PCI MEM: 0x80000000 - 0xbfffffff
* PCI MEM: 0x00000000 -> Processor System Memory: 0x00000000
* EUMB mapped to: ioremap_base - 0x00100000 (ioremap_base - 1 MB)
seems to contradict with the above map in pci io area, as well as this
one:
* Want processor accesses of 0xFDxxxxxx to be mapped
* to PCI memory space at 0x00000000. Do not want
Actually, I cannot even match these 2 together?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ 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