* Re: [RFC] Interrupt mapping documentation
From: Segher Boessenkool @ 2006-06-19 23:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Becky Bruce, linuxppc-dev list
In-Reply-To: <E1FsSmY-0000Oz-P2@jdl.com>
>> Just *require* #address-cells for everything with addressable sub-
>> nodes,
>> at least in DTC. Doesn't cost much, and no confusion anymore.
>
> Woot! Send me a patch! :-)
Noooo... tiiiime... And way too lazy.
Could you pick this up, please?
Segher
^ permalink raw reply
* Re: [PATCH 5/9 v3] Add the MPC8641 HPCN platform files.
From: Jon Loeliger @ 2006-06-19 23:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <A609CF22-66E8-404C-A6F2-528BE097BF57@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
>
> In that case you obviously need to sync the timebases, sure.
> The firmware could be smart and do the sync at CPU start-up
> time though.
I am investigating this and, as I indicated to Ben, submit
a follow up patch to implement it if I figure out to do it.
> In
> some cases the kernel explicitly tells the firmware to start/
> stop the timebases, that's better than the kernel having to
> handle the nitty-gritty details itself already.
>
> Thoughts?
Well, by the time Linux is running, there is no more firmware
available. Linux is essentially autononomous at this stage,
and I think it will have to arrange for the TB sync itself.
jdl
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Benjamin Herrenschmidt @ 2006-06-19 23:12 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list
In-Reply-To: <EC61A880-9242-4BCE-B72D-8AFC038CD592@freescale.com>
> One concern is this stated requirement that a tree have an interrupt-
> controller node. It's not uncommon (in fact, I'm doing it right
> now...) for FSL and some of our customers to build and run the kernel
> on a simulator that has only a processor core, memory, and a memory-
> mapped pseudo-terminal. The terminal does not generate interrupts,
> but is polled from the Decrementer interrupt. So I do not have an
> interrupt controller in the "system" at all.
You don't need an interrupt controller if you don't take interrupts ;)
> How are you planning to enforce this requirement? I believe the dtc
> I have right now warns me about no interrupt-controller node, but it
> builds the tree anyway, and I can boot my kernel just fine. If all
> I'll need to do to get this working in the new world order is to add
> an "interrupt-controller" property to my soc node, I can deal with
> that. I just don't want the kernel to konk out and refuse to boot if
> it doesn't find any interrupts.
If you don't have interrupts, there is no problem. If you do, well, in
fact, I wrote my remapping core in such a way that it _can_ work without
interrupt controller nodes. There are ways to hack around... But you
won't be able to use the OF-parsing facilities to obtain interrupt
mapping of course.
I suppose I should update the above to say "If your platform can handle
external interrupts..."
> > 3) Representing devices without a current OF specification
> > @@ -1263,11 +1305,12 @@
> >
> > Example :
> >
> > - pic@40000 {
> > + interrupt-controller@40000 {
> > linux,phandle = <40000>;
> > clock-frequency = <0>;
> > interrupt-controller;
> > #address-cells = <0>;
> > + #interrupt-cells = <2>;
> > reg = <40000 40000>;
> > built-in;
> > compatible = "chrp,open-pic";
> > @@ -1445,6 +1488,314 @@
> I'm curious about why you chose to rename the pic node here - now we
> have interrupt-controller as a device name, as well as an interrupt-
> controller property inside the device. Reading the rest of this doc,
> the latter should be sufficient. Is this just a stylistic decision?
It's a common practice to name it that way, like it's a common practice
to name ethernet controllers "ethernet"... doesn't _have_ to be that
way. There is an OF RFC or something, I cna't remember the details, that
defines that kind of standard naming.
> >
> > +1) Interrupt controllers
> > +------------------------
> > +
> > +An interrupt controller is identified by the presence of an empty
> > +"interrupt-controller" property in the node. It must also have those
> > +two required properties:
> > +
> > + - linux,phandle : The normally optional phandle is required
> > for an
> > + interrupt controller node as that node will have to be
> > + referrenced by phandle by other nodes (childs and nexus).
> > + - #interrupt-cells : This property contains one cell indicating
> > + the size of the child interrupt specifiers (number of
> > + cells). For example, both ISA and OpenPIC standard specifiers
> > + are 2 cells long (interrupt source number and trigger type)
> > thus
> > + the interrupt-controller node for these shall contain a
> > + #interrupt-cells property with the value <2>.
> > +
> > +In addition, it needs that optional property if there is ever a nexus
> > +pointing to that controller:
> > +
> > + - #address-cells : This is generally the value 0 for an interrupt
> > + controller, the reason why this property is needed is described
> > + in the documentation of an interrupt nexus.
> > +
>
> I think there is some potential for confusion to the reader about the
> required use of #address-cells. In the original document, we talk
> about how devices without an #address-cells property derive the value
> from the parent:
Which is incorrect according to the spec. It's a "feature" we had in the
kernel to work around a ouple of broken device-trees in early Apple OFs
iirc, and when drafting that initial spec, I incorrectly assumed it was
standard OF.
> "In general, the format of an address for a device is defined by the
> parent bus type, based on the #address-cells and #size-cells
> property. In the absence of such a property, the parent's parent
> values are used, etc..."
Yes, and that's wrong. In the case of an interrupt nexus, I would like
to enforce it anyway for various reasons, like the fact that it
simplifies the parsing when hop'ing through more than one interrupt
parent to require explicit #address-cells on interrupt controllers and
interrupt nexus.
> The additions in the patch specify new requirements that don't seem
> to match up with the statement above. In the new patch, #address-
> cells is listed as a required node for interrupt-controller nodes,
> there's no mention of inheritance from a parent, and in one place in
> the Nexus section, it's stated that if there's no #address-cells node
> the kernel assumes it's 0.
>
> I think the doc needs a bit of clarification in this area.
Yup. #address-cells is mandatory to be able to parse the "parent" unit
interrupt specifier part of an interrupt-map. Thus the interrupt
controller must provide one. Since in most case, the parent unit
interrupt specifiers don't contain a unit address, but just an interrupt
line and sense, thus interrupt-controllers shall expose that by having a
#address-cells with a value of 0.
Now regarding default values, it's unclear. The OF interrupt mapping
document seems to imply that when parsing the interrupt tree, the
absence of a #address-cells in the interrupt parent means no unit
address while the OF spec defines a default value of 2 for a missing
#address-cells when parsing device addresse...
> I think it would be useful to continue the example here, and show an
> "interrupt-map" property definition with all the fields filled in.
That's the goal :) I didn't have time to write examples yet.
> Perhaps you were planning to do this as part of your PCI examples; if
> so just ignore this.
Yes. PCI is the typical case of using interrupt-map's
Ben.
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Jon Loeliger @ 2006-06-19 23:14 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Becky Bruce, linuxppc-dev list
In-Reply-To: <72C71D61-F43A-4644-BBE8-F8B3B8526195@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
> >> Just *require* #address-cells for everything with addressable sub-
> >> nodes,
> >> at least in DTC. Doesn't cost much, and no confusion anymore.
> >
> > Woot! Send me a patch! :-)
>
> Noooo... tiiiime... And way too lazy.
Jinx.
> Could you pick this up, please?
I would not be able to get anywhere near it until
significantly into August at the very earliest.
Really.
jdl
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Benjamin Herrenschmidt @ 2006-06-19 23:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Becky Bruce, linuxppc-dev list
In-Reply-To: <3E324A7E-388E-4917-B380-B0831A5F9D19@kernel.crashing.org>
> If there's any interrupt in the dev tree, there should be an interrupt
> controller. If the requirement is more strict than that, that's a
> bug :-)
Yes, I should make that clearer.
> Most "real" device trees (on a "real" OF) do not have "interrupt-
> controller"
> as the name of their main interrupt controller nodes. This sounds
> like a
> spec bug.
I haven't specified that it _should_ be called interrupt-controller, but
it's generally called that way at least on chrp/pSeries and I think
there's an OF recommended practices RFC that says something around those
lines, so I changed the examples to reflect that.
> > "In general, the format of an address for a device is defined by the
> > parent bus type, based on the #address-cells and #size-cells
> > property. In the absence of such a property, the parent's parent
> > values are used, etc..."
>
> Bad already; #size-cells has nothing to do with addresses (it's
> important for address _ranges_ though).
That's an old bit of the spec that you could have commented on a long
time ago :) Though a "reg" property contains an address range and the
above was talking about those mostly. I need to clarify. In addition,
the default-to-parent thing is something I'll remove from the spec and
write that the absence of the property is undefined I think. We'll keep
the current behaviour in linux for now though.
> > The additions in the patch specify new requirements that don't seem
> > to match up with the statement above. In the new patch, #address-
> > cells is listed as a required node for interrupt-controller nodes,
> > there's no mention of inheritance from a parent,
>
> Inheritance from the parent does not exist, in real OF. Absence of
> #address-cells means "default to 2". This needs to be fixed in DTC.
Yes. Except that I will probably not do the "default to 2". The kernel
doesn't do it and there might still be things relying on the old
(broken) linux behaviour. Thus I'll probably spec it as undefined.
> > and in one place in
> > the Nexus section, it's stated that if there's no #address-cells node
> > the kernel assumes it's 0.
>
> Also wrong. Although I think that's what the IMAP thing says as well...
Yes, it seems the default is different when parsing interrupts... at
least when hitting an interrupt-controller node, which is not a standard
address parsing.
> > I think the doc needs a bit of clarification in this area.
>
> Yeah.
>
> Just *require* #address-cells for everything with addressable sub-nodes,
> at least in DTC. Doesn't cost much, and no confusion anymore.
Yes. We should do that.
In the case of interrupt controllers/nexus, #address-cells is not for
addressable sub-nodes though but for defining the format of unit
interrupt specifiers for interrupt-childs which aren't necessary sub
nodes... confusing heh ?
Ben
^ permalink raw reply
* Re: [PATCH 5/9 v3] Add the MPC8641 HPCN platform files.
From: Segher Boessenkool @ 2006-06-19 23:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FsSuB-0000Qc-P6@jdl.com>
>> In that case you obviously need to sync the timebases, sure.
>> The firmware could be smart and do the sync at CPU start-up
>> time though.
>
> I am investigating this and, as I indicated to Ben, submit
> a follow up patch to implement it if I figure out to do it.
Great.
>> In
>> some cases the kernel explicitly tells the firmware to start/
>> stop the timebases, that's better than the kernel having to
>> handle the nitty-gritty details itself already.
>>
>> Thoughts?
>
> Well, by the time Linux is running, there is no more firmware
> available. Linux is essentially autononomous at this stage,
> and I think it will have to arrange for the TB sync itself.
I'm confused now. So are or arent't all CPUs running at the
time Linux is started? Are you saying Linux manually starts
all non-boot CPUs?!?
Segher
^ permalink raw reply
* Linux on Virtex4
From: Martin, Tim @ 2006-06-19 23:24 UTC (permalink / raw)
To: linuxppc-embedded
I have been working with a small module made by Memec/Avnet
(FX12MM1-BASE) that has a Virtex-4 FX12 with some DDR SDRAM, a Gigabit
Ethernet PHY, some FLASH, etc. I am using EDK 8.1 and generated the BSP
for MontaVista 3.1 "preview kit" (which is based on the 2.4.20 kernel).
This works, but occasionally panics while booting (doesn't panic all the
time, maybe 1/3 the time). Examples of "good" boot and 2 "crash" boots
below. We are using a root filesystem over NFS, and the panics seem to
always be after the file system is mounted. I'm not sure if it is NFS
related or not.
I have also been working with the paulus 2.6 kernel tree (and I have
tried the MVL linux-xilinx-26 tree), but have not been able to get the
kernel to boot. The primary problem there is that we are using the
uartlite instead of the full uart, and the patches I have found for
uartlite support don't work. I can get the early serial messages to
work, but I don't know enough about the console and serial core to get
everything else working. I am also getting panics that seem to be
non-serial related, but I haven't tracked it down yet.
So two questions:
1) Is there anything obvious from the kernel panics below that I should
be looking for? Just the answer "linux 2.4.20 is really fricken old,
upgrade" is probably the right answer.
2) Does anyone have working UartLite support on a Virtex-4 FX12 design?
------------ Examples of 2.4.20 good:
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
Linux version 2.4.20_mvl31-v4fx12 (ahamel@uhflinux) (gcc version 3.3.1
(MontaVista 3.3.1-3.0.10.6
setup_arch: enter
setup_arch: bootmem
Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc.
(source@mvista.com)
arch: exit
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/nfs
nfsroot=3D192.168.1.1:/opt/montavista/previewkit/ppc/405/target4
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
Calibrating delay loop... 197.01 BogoMIPS
Memory: 63268k available (1092k kernel code, 340k data, 60k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 42
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
xgpio #0 at 0x40020000 mapped to 0xC5000000
xgpio #1 at 0x40040000 mapped to 0xC5011000
xgpio #2 at 0x40060000 mapped to 0xC5022000
xilinx_spi: got major number 254
xilinx_spi0 at 0x40800000 mapped to 0xC5033000, irq=3D29
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
XTemac: Device instance #0 found
eth0: XTemac: using fifo direct interrupt driven mode.
eth0: XTemac: PHY detected at address 4.
eth0: Xilinx TEMAC #0 at 0x80400000 mapped to 0xC5044000, irq=3D28
eth0: XTemac: id 1.0f, block id 5, type 8
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
eth0: XTemac: Options: 0xb8f0
eth0: XTemac: We renegotiated the speed to: 1000
eth0: XTemac: speed set to 1000Mb/s
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.75
IP-Config: Complete:
device=3Deth0, addr=3D192.168.1.75, mask=3D255.255.255.0,
gw=3D192.168.1.1,
host=3D192.168.1.75, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.1.1, rootserver=3D192.168.1.1, rootpath=3D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 60k init
serial console detected. Disabling virtual terminals.
init started: BusyBox v0.60.2 (2004.04.30-17:49+0000) multi-call binary
Welcome to MontaVista Linux Preview Kit
Starting system...
mounting /proc: done.
Mounting '/' read-only: done.
brining up loopback interface: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting inetd: done.
Starting thttpd: done.
System started.
MontaVista(R) Linux(R) Professional Edition 3.1, Preview Kit
192.168.1.75 login:
------ Example 1 of panic
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
Linux version 2.4.20_mvl31-v4fx12 (ahamel@uhflinux) (gcc version 3.3.1
(MontaVista 3.3.1-3.0.10.6
setup_arch: enter
setup_arch: bootmem
Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc.
(source@mvista.com)
arch: exit
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/nfs
nfsroot=3D192.168.1.1:/opt/montavista/previewkit/ppc/405/target4
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
Calibrating delay loop... 197.01 BogoMIPS
Memory: 63268k available (1092k kernel code, 340k data, 60k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 42
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
xgpio #0 at 0x40020000 mapped to 0xC5000000
xgpio #1 at 0x40040000 mapped to 0xC5011000
xgpio #2 at 0x40060000 mapped to 0xC5022000
xilinx_spi: got major number 254
xilinx_spi0 at 0x40800000 mapped to 0xC5033000, irq=3D29
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
XTemac: Device instance #0 found
eth0: XTemac: using fifo direct interrupt driven mode.
eth0: XTemac: PHY detected at address 4.
eth0: Xilinx TEMAC #0 at 0x80400000 mapped to 0xC5044000, irq=3D28
eth0: XTemac: id 1.0f, block id 5, type 8
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
eth0: XTemac: Options: 0xb8f0
eth0: XTemac: We renegotiated the speed to: 1000
eth0: XTemac: speed set to 1000Mb/s
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.75
IP-Config: Complete:
device=3Deth0, addr=3D192.168.1.75, mask=3D255.255.255.0,
gw=3D192.168.1.1,
host=3D192.168.1.75, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.1.1, rootserver=3D192.168.1.1, rootpath=3D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 60k init
nfs: server 192.168.1.1 not responding, still trying
Oops: kernel access of bad area, sig: 11
NIP: C00F05B4 XER: 20000000 LR: C00F0C80 SP: C0131C80 REGS: c0131bd0
TRAP: 0800 Not tainted
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DEAR: 00000045, ESR: 00000000
TASK =3D c0130020[0] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: C00CA728 C0131C80 C0130020 00000001 00001030 00000000 C02C9180
C023F9F8
GPR08: C02CA000 C0150000 00000003 00001DC7 84002022 1006E950 03FD0000
00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 00001032 00131EE0 00000000
C0000000
GPR24: C0151D24 C02C90D0 C0150000 00000000 C0157F00 C02E8080 C02C90D8
C02E8080
Call backtrace:
C00F0A4C C00CA728 C00EED30 C00C2958 C00200DC C001BD20 C001BB9C
C001B868 C0005E48 C00047CC C00274E4 C0005D80 C0005D94 C0002434
C01425CC C000232C
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<0>Rebooting in 180 seconds..
------- Example 2 of crash
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:mapin_ram done
MMU:setio
MMU:exit
Linux version 2.4.20_mvl31-v4fx12 (ahamel@uhflinux) (gcc version 3.3.1
(MontaVista 3.3.1-3.0.10.6
setup_arch: enter
setup_arch: bootmem
Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc.
(source@mvista.com)
arch: exit
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/nfs
nfsroot=3D192.168.1.1:/opt/montavista/previewkit/ppc/405/target4
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
Calibrating delay loop... 197.01 BogoMIPS
Memory: 63268k available (1092k kernel code, 340k data, 60k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 42
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
xgpio #0 at 0x40020000 mapped to 0xC5000000
xgpio #1 at 0x40040000 mapped to 0xC5011000
xgpio #2 at 0x40060000 mapped to 0xC5022000
xilinx_spi: got major number 254
xilinx_spi0 at 0x40800000 mapped to 0xC5033000, irq=3D29
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
XTemac: Device instance #0 found
eth0: XTemac: using fifo direct interrupt driven mode.
eth0: XTemac: PHY detected at address 4.
eth0: Xilinx TEMAC #0 at 0x80400000 mapped to 0xC5044000, irq=3D28
eth0: XTemac: id 1.0f, block id 5, type 8
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
eth0: XTemac: Options: 0xb8f0
eth0: XTemac: We renegotiated the speed to: 1000
eth0: XTemac: speed set to 1000Mb/s
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.75
IP-Config: Complete:
device=3Deth0, addr=3D192.168.1.75, mask=3D255.255.255.0,
gw=3D192.168.1.1,
host=3D192.168.1.75, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.1.1, rootserver=3D192.168.1.1, rootpath=3D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 60k init
serial console detected. Disabling virtual terminals.
init started: BusyBox v0.60.2 (2004.04.30-17:49+0000) multi-call binary
Welcome to MontaVista Linux Preview Kit
Starting system...
mounting /proc: done.
Mounting '/' read-only: done.
brining up loopback interface: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting inetd: done.
Starting thttpd: done.
System started.
Oops: Exception in kernel mode, sig: 4
NIP: C010D660 XER: 00000000 LR: C010D6F0 SP: C3EB7E60 REGS: c3eb7db0
TRAP: 0700 Not tainted
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK =3D c3eb6000[48] 'insmod' Last syscall: 90
last math 00000000 last altivec 00000000
GPR00: 00000001 C3EB7E60 C3EB6000 C3F06CD8 C014F524 C014DAE0 C014DB00
C014DAF8
GPR08: C014D000 C3F06C78 0000001C C014D9D8 24022222 00000000 300277F8
00000000
GPR16: 10001AA1 7FFFF118 00000030 C0150000 00000000 FFFFFFF4 00000002
00000002
GPR24: 00100077 00000032 00000000 00000001 C014F524 C014DAF8 C3F06CD8
C014D9D8
Call backtrace:
C002A84C C0029684 C0029BC0 C0009DE0 C000459C 3000646C 30007784
3000B810 3000CE68 3000C1F8 30002FE8 3000F7F0 30001FDC 30002434
30010904
kernel BUG at mmap.c:1304!
Oops: Exception in kernel mode, sig: 4
NIP: C002AD48 XER: 00000000 LR: C002AD48 SP: C3EB7C60 REGS: c3eb7bb0
TRAP: 0700 Not tainted
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK =3D c3eb6000[48] 'insmod' Last syscall: 90
last math 00000000 last altivec 00000000
GPR00: C002AD48 C3EB7C60 C3EB6000 0000001B 00001030 00000001 00000F14
C0139D93
GPR08: 00000000 00000000 00000034 C3EB7B70 C0150000 00000000 300277F8
00000000
GPR16: 10001AA1 7FFFF118 00000030 C0150000 00009032 03EB7DA0 00000000
C00047D4
GPR24: C0004BC4 C0150000 C0150000 00000000 00001000 7FFFF000 C014F520
00000000
Call backtrace:
C002AD48 C0014684 C0019EE8 C000497C C00049EC C00047D4 C002A84C
C0029684 C0029BC0 C0009DE0 C000459C
^ permalink raw reply
* Re: OFW node names
From: Doug Maxey @ 2006-06-19 23:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <41C6BB03-59B9-4954-815B-7750B0996AB9@kernel.crashing.org>
On Tue, 20 Jun 2006 00:11:55 +0200, Segher Boessenkool wrote:
> > Does any platform known to use yaboot (or grub for that matter) use
> > the
> > preferred encoding of the manufacturer portion of the name property?
> > How about the "ONNNNN" OUI from the RAC, or the uppercase VWXYZ
> > company stock symbol?
>
> Apple sometimes uses AAPL. Never seen the ONNNNNN thing.
matches the US stock symbol, goodness.
>
> > My view has been limited to the IBM platform. According to the
> > examples, this is a recommended practice. I know IBM uses the
> > lowercase variant.
>
> Which _is_ allowed, although discouraged.
Ok, but who enforces it? Vendor polices themselves? Right. :->
Thanks!
++doug
^ permalink raw reply
* Re: [PATCH 5/9 v3] Add the MPC8641 HPCN platform files.
From: Jon Loeliger @ 2006-06-19 23:32 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <F5D6E2FC-CE35-4681-9F42-A1B4E2BFE097@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
>
> I'm confused now. So are or arent't all CPUs running at the
> time Linux is started?
Only the boot CPU is running. The others are not.
> Are you saying Linux manually starts
> all non-boot CPUs?!?
Right. The secondary CPUs are not clocking, not able to
fetch memory, not nothing until Linux gets a shot at
smp_secondary_kick()'ing them into motion. And then we
have the ability to start the scondary CPUs one at a time.
jdl
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Segher Boessenkool @ 2006-06-19 23:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Becky Bruce, linuxppc-dev list
In-Reply-To: <1150759075.23600.297.camel@localhost.localdomain>
>> Most "real" device trees (on a "real" OF) do not have "interrupt-
>> controller"
>> as the name of their main interrupt controller nodes. This sounds
>> like a
>> spec bug.
>
> I haven't specified that it _should_ be called interrupt-
> controller, but
> it's generally called that way at least on chrp/pSeries and I think
> there's an OF recommended practices RFC that says something around
> those
> lines, so I changed the examples to reflect that.
In my opinion, the device _name_ should in the first place be useful
to the human user, so be a _bit_ detailed, although not to much. The
various OF documents, no matter what their status, seem to swing one
way or the other though.
Anyway, "mpic" or "openpic" are very common interrupt controller
device node names as well.
>>> "In general, the format of an address for a device is defined by the
>>> parent bus type, based on the #address-cells and #size-cells
>>> property. In the absence of such a property, the parent's parent
>>> values are used, etc..."
>>
>> Bad already; #size-cells has nothing to do with addresses (it's
>> important for address _ranges_ though).
>
> That's an old bit of the spec that you could have commented on a long
> time ago :)
I never read the thing before ;-P [Or detailed enough to comment on
it, anyway]. Doesn't mean you shouldn't fix it :-)
> Though a "reg" property contains an address range and the
This is not true in general. There's nodes with #size-cells = 0...
Degenerate range yeah, yadda yadda.
> above was talking about those mostly. I need to clarify.
Please!
> In addition,
> the default-to-parent thing is something I'll remove from the spec and
> write that the absence of the property is undefined I think.
Great. The "default to two" thing is just a compatibility thing for old
old OpenBoot afaict anyway.
> We'll keep
> the current behaviour in linux for now though.
Fine of course.
>>> The additions in the patch specify new requirements that don't seem
>>> to match up with the statement above. In the new patch, #address-
>>> cells is listed as a required node for interrupt-controller nodes,
>>> there's no mention of inheritance from a parent,
>>
>> Inheritance from the parent does not exist, in real OF. Absence of
>> #address-cells means "default to 2". This needs to be fixed in DTC.
>
> Yes. Except that I will probably not do the "default to 2". The kernel
> doesn't do it and there might still be things relying on the old
> (broken) linux behaviour. Thus I'll probably spec it as undefined.
Error or warning, in the compiler? My vote is error...
>>> and in one place in
>>> the Nexus section, it's stated that if there's no #address-cells
>>> node
>>> the kernel assumes it's 0.
>>
>> Also wrong. Although I think that's what the IMAP thing says as
>> well...
>
> Yes, it seems the default is different when parsing interrupts... at
> least when hitting an interrupt-controller node, which is not a
> standard
> address parsing.
This in practice would apply to interrupt controller nodes that are
a _real_ interrupt controller, so not a parent of a bus, so a) no
child nodes that need addresses, and b) indeed no interrupt unit spec
to care about, for the incoming interrupts. It's still ugly though :-(
>>> I think the doc needs a bit of clarification in this area.
>>
>> Yeah.
>>
>> Just *require* #address-cells for everything with addressable sub-
>> nodes,
>> at least in DTC. Doesn't cost much, and no confusion anymore.
>
> Yes. We should do that.
Oh, agreement!
> In the case of interrupt controllers/nexus, #address-cells is not for
> addressable sub-nodes though but for defining the format of unit
> interrupt specifiers for interrupt-childs which aren't necessary sub
> nodes... confusing heh ?
You want confusing? You can have the situation where some of those
interrupt children *are* bus children, as well! *And* some are not.
No I still havent't figured out the complete IMAP-compatible interrupt
map for JS21 yet.
Segher
^ permalink raw reply
* Re: [PATCH 5/9 v3] Add the MPC8641 HPCN platform files.
From: Segher Boessenkool @ 2006-06-19 23:36 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FsTE0-0000U4-Mp@jdl.com>
>> Are you saying Linux manually starts
>> all non-boot CPUs?!?
>
> Right. The secondary CPUs are not clocking, not able to
> fetch memory, not nothing until Linux gets a shot at
> smp_secondary_kick()'ing them into motion. And then we
> have the ability to start the scondary CPUs one at a time.
So you start them with a GPIO? Would it be feasible to
sync the time bases right there? Constrain the ugliness
to just that one spot, as it were. Although it ends up
with the same complexity, sigh.
Segher
^ permalink raw reply
* Re: Linux on Virtex4
From: Grant Likely @ 2006-06-19 23:38 UTC (permalink / raw)
To: Martin, Tim; +Cc: linuxppc-embedded
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE48710573FD21@VCAEXCH01.hq.corp.viasat.com>
On 6/19/06, Martin, Tim <tim.martin@viasat.com> wrote:
>
> 1) Is there anything obvious from the kernel panics below that I should
> be looking for? Just the answer "linux 2.4.20 is really fricken old,
> upgrade" is probably the right answer.
I've seen kernel panics when booting large kernel images (>1.5M),
especially when I've welded the kernel image to a system.ace file for
booting via CF. I haven't tracked down the root cause. I use both
2.4 and 2.6, and I've seen kernel panics with both. In your case,
you'll need to decode the backtrace to find out where the kernel is
panicing
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 5/9 v3] Add the MPC8641 HPCN platform files.
From: Jon Loeliger @ 2006-06-19 23:52 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <BF0ECF8F-8083-47E7-A0DB-76801C7E8ADD@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
> So you start them with a GPIO?
Yeah, magic system register write.
> Would it be feasible to
> sync the time bases right there? Constrain the ugliness
> to just that one spot, as it were. Although it ends up
> with the same complexity, sigh.
That's the sort of thing I will be investigating, yep...
jdl
^ permalink raw reply
* Re: OFW node names
From: Segher Boessenkool @ 2006-06-20 0:00 UTC (permalink / raw)
To: Doug Maxey; +Cc: linuxppc-dev
In-Reply-To: <20060619233155.361570@bebe.enoyolf.org>
>> Apple sometimes uses AAPL. Never seen the ONNNNNN thing.
>
> matches the US stock symbol, goodness.
Yeah. Wow. They also use "aapl", of course -- or nothing
at all. Or "apl" in at least one case.
>>> My view has been limited to the IBM platform. According to the
>>> examples, this is a recommended practice. I know IBM uses the
>>> lowercase variant.
>>
>> Which _is_ allowed, although discouraged.
>
> Ok, but who enforces it? Vendor polices themselves? Right. :->
If there is a comma, the part before the first comma is supposed
to be a vendor identifier. The actual format of that is allowed
to be basically anything, even by the OF standard itself. The
less ambiguous formats are encouraged though...
Segher
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Becky Bruce @ 2006-06-20 0:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1150759075.23600.297.camel@localhost.localdomain>
On Jun 19, 2006, at 6:17 PM, Benjamin Herrenschmidt wrote:
>
>> If there's any interrupt in the dev tree, there should be an
>> interrupt
>> controller. If the requirement is more strict than that, that's a
>> bug :-)
>
> Yes, I should make that clearer.
Yes, please! These things might seem obvious, but I've been burned
by somewhat arbitrary requirements enough in the past to be wary.
Paranoid, even :)
>
>> Most "real" device trees (on a "real" OF) do not have "interrupt-
>> controller"
>> as the name of their main interrupt controller nodes. This sounds
>> like a
>> spec bug.
>
> I haven't specified that it _should_ be called interrupt-
> controller, but
> it's generally called that way at least on chrp/pSeries and I think
> there's an OF recommended practices RFC that says something around
> those
> lines, so I changed the examples to reflect that.
If there's precedence for it, it's fine with me. I was just curious
about why it changed. Personally, I'd rather see it as "pic",
because that's more specific, and it's the actual device name, but
it's not keeping me up at night.....
> In addition,
> the default-to-parent thing is something I'll remove from the spec and
> write that the absence of the property is undefined I think. We'll
> keep
> the current behaviour in linux for now though.
That also works for me. I'd rather have to specify more stuff in the
tree and have it be crystal clear how it's interpreted and used. So,
is this true for just #address-cells, or does it affect #size-cells
as well?
>
>>> The additions in the patch specify new requirements that don't seem
>>> to match up with the statement above. In the new patch, #address-
>>> cells is listed as a required node for interrupt-controller nodes,
>>> there's no mention of inheritance from a parent,
>>
>> Inheritance from the parent does not exist, in real OF. Absence of
>> #address-cells means "default to 2". This needs to be fixed in DTC.
>
> Yes. Except that I will probably not do the "default to 2". The kernel
> doesn't do it and there might still be things relying on the old
> (broken) linux behaviour. Thus I'll probably spec it as undefined.
Sounds good. The dtc should probably throw an error (or at least a
warning) on this, so the trees get fixed. I think I'd prefer to see
an error - that will keep this problem from propagating any further.
>>
>> Just *require* #address-cells for everything with addressable sub-
>> nodes,
>> at least in DTC. Doesn't cost much, and no confusion anymore.
>
> Yes. We should do that.
I agree 100%.
>
> In the case of interrupt controllers/nexus, #address-cells is not for
> addressable sub-nodes though but for defining the format of unit
> interrupt specifiers for interrupt-childs which aren't necessary sub
> nodes... confusing heh ?
Um, yeah :) I think with a little clarification it will be fine,
though.
Thanks!
-B
^ permalink raw reply
* powerpc: disable floating point exceptions for init
From: Arnd Bergmann @ 2006-06-20 0:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, cbe-oss-dev
Floating point exceptions should not be enabled by default,
as this setting impacts the performance on some CPUs, in
particular the Cell BE. Since the bits are inherited from
parent processes, the place to change the default is the
thread struct used for init.
glibc sets this up correctly per thread in its fesetenv
function, so user space should not be impacted by this
setting. None of the other common libc implementations
(uClibc, dietlibc, newlib, klibc) has support for fp
exceptions, so they are unlikely to be hit by this either.
There is a small risk that somebody wrote their own
application that manually sets the fpscr bits instead
of calling fesetenv, without changing the MSR bits as well.
Those programs will break with this change.
It probably makes sense to change glibc in the future
to be more clever about FE bits, so that when running
on a CPU where this is expensive, it disables exceptions
ASAP, while it keeps them enabled on CPUs where running
with exceptions on is cheaper than changing the state
often.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
Index: linus-2.6/include/asm-powerpc/processor.h
===================================================================
--- linus-2.6.orig/include/asm-powerpc/processor.h
+++ linus-2.6/include/asm-powerpc/processor.h
@@ -190,7 +190,7 @@ struct thread_struct {
.fs = KERNEL_DS, \
.fpr = {0}, \
.fpscr = { .val = 0, }, \
- .fpexc_mode = MSR_FE0|MSR_FE1, \
+ .fpexc_mode = 0, \
}
#endif
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Segher Boessenkool @ 2006-06-20 0:39 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list
In-Reply-To: <40AABEB6-3467-4AFB-BC7B-08176EDD61E2@freescale.com>
>> I haven't specified that it _should_ be called interrupt-
>> controller, but
>> it's generally called that way at least on chrp/pSeries and I think
>> there's an OF recommended practices RFC that says something around
>> those
>> lines, so I changed the examples to reflect that.
>
> If there's precedence for it, it's fine with me. I was just
> curious about why it changed. Personally, I'd rather see it as
> "pic", because that's more specific, and it's the actual device
> name, but it's not keeping me up at night.....
I'll just say that _I_ care :-)
>> In addition,
>> the default-to-parent thing is something I'll remove from the spec
>> and
>> write that the absence of the property is undefined I think. We'll
>> keep
>> the current behaviour in linux for now though.
>
> That also works for me. I'd rather have to specify more stuff in
> the tree and have it be crystal clear how it's interpreted and
> used. So, is this true for just #address-cells, or does it affect
> #size-cells as well?
#size-cells defaults to 1, it isn't inherited either. So same story.
>>>> The additions in the patch specify new requirements that don't seem
>>>> to match up with the statement above. In the new patch, #address-
>>>> cells is listed as a required node for interrupt-controller nodes,
>>>> there's no mention of inheritance from a parent,
>>>
>>> Inheritance from the parent does not exist, in real OF. Absence of
>>> #address-cells means "default to 2". This needs to be fixed in DTC.
>>
>> Yes. Except that I will probably not do the "default to 2". The
>> kernel
>> doesn't do it and there might still be things relying on the old
>> (broken) linux behaviour. Thus I'll probably spec it as undefined.
>
> Sounds good. The dtc should probably throw an error (or at least a
> warning) on this, so the trees get fixed. I think I'd prefer to
> see an error - that will keep this problem from propagating any
> further.
Error please... If the new DTC spec will require it, it should
be an error.
>>> Just *require* #address-cells for everything with addressable sub-
>>> nodes,
>>> at least in DTC. Doesn't cost much, and no confusion anymore.
>>
>> Yes. We should do that.
>
> I agree 100%.
No dissenters anywhere? Please? Can't we have a fight?
>> In the case of interrupt controllers/nexus, #address-cells is not for
>> addressable sub-nodes though but for defining the format of unit
>> interrupt specifiers for interrupt-childs which aren't necessary sub
>> nodes... confusing heh ?
>
> Um, yeah :) I think with a little clarification it will be fine,
> though.
As long as your interrupt tree is a) completely independent of your bus
tree (and then, only in most cases), or b) completely follows the bus
tree.
Sigh.
On almost all platforms, this shouldn't cause any real problems, though.
Segher
^ permalink raw reply
* Unable to handle kernel paging request in show_instructions
From: David Wilder @ 2006-06-20 0:42 UTC (permalink / raw)
To: Linuxppc-dev
I ran into the following problem during Oops processing:
Oops: Exception in kernel mode, sig: 4 [#1]
SMP NR_CPUS=128 NUMA PSERIES LPAR
Modules linked in: pitrace sg scsi_mod nfs lockd nfs_acl sunrpc ipv6
apparmor aa match_pcre loop dm_mod tg3
NIP: D000000000022014 LR: C000000000018FE4 CTR: C00000000036C718
REGS: c00000000043faf0 TRAP: 0700 Tainted: G U
(2.6.16.16-1.6-ppc64-wilder)
MSR: 8000000000089432 <EE,ME,IR,DR> CR: 24000088 XER: 000FFFFF
TASK = c00000000048a660[0] 'swapper' THREAD: c00000000043c000 CPU: 0
GPR00: C000000000018FE4 C00000000043FD70 C000000000624420 0000000000000000
GPR04: C00000000048A990 0000000000006DFF 0000000024000082 C00000000000F0B0
GPR08: 0000000000000000 C0000000004351C0 0000000001021A00 C000000001456BC0
GPR12: D0000000004CC2B8 C00000000048AE80 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 4000000000400000 C00000000042BA00 C00000000042BEA8 C00000000042BC70
GPR24: C00000000048AE80 000000000082BA00 0000000000000000 C000000000000000
GPR28: 00000000FFFFFFFF C000000000629070 C0000000004C7BC8 C00000000F9F89D0
NIP [D000000000022014] 0xd000000000022014
LR [C000000000018FE4] .default_idle+0x98/0xcc
Call Trace:
[C00000000043FD70] [C000000000018FE4] .default_idle+0x98/0xcc (unreliable)
[C00000000043FE00] [C000000000018F38] .cpu_idle+0x40/0x54
[C00000000043FE70] [C000000000009274] .rest_init+0x44/0x5c
[C00000000043FEF0] [C0000000003FC75C] .start_kernel+0x270/0x288
[C00000000043FF90] [C000000000008594] .start_here_common+0x88/0x8c
Instruction dump:
>>>Unable to handle kernel paging request for data at address
0xd000000000021fe4
>>>Faulting instruction address: 0xc00000000036b960
I don't care about the original oops, only the second fault because it
prevents kdump from starting.
The problem occures in show_instructions(). Show_instructions() takes
the NIP (D00000000002201) and subtracts some number so it points several
instructs before the failing instructions. In this case the new value
is on a previous page and that page is not valid (it is not mapped).
When the new NIP is referenced we get a second fault.
show_instructions tries to validate addresses by checking if it is the
kernel segment (0xc.....) or the first vmalloc segment (0xD.......).
But in this case the validation passes even though the address is
invalid. Any ideas how to fix this? Is there a easy way to validate
if a page is valid before accessing it?
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
^ permalink raw reply
* Re: Unable to handle kernel paging request in show_instructions
From: Arnd Bergmann @ 2006-06-20 0:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4497445F.50700@us.ibm.com>
On Tuesday 20 June 2006 02:42, David Wilder wrote:
> But in this case the validation passes even though the address is
> invalid. Any ideas how to fix this? Is there a easy way to validate
> if a page is valid before accessing it?
The check that kallsyms_lookup does should find this, but it may
be overkill to call that function just to verify an address.
You might also have success calling vmalloc_to_page for a 0xd000...
address to check if that is really mapped.
Arnd <><
^ permalink raw reply
* RE: Using bestcomm in an external module (MPC5200B to be exact)
From: Trueskew @ 2006-06-20 0:48 UTC (permalink / raw)
To: 'John Rigby'; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0606191432n332a23d0se0f93e2204e47dd9@mail.gmail.com>
John, would you happen to know where I'd find the latest? The LTIB I have
is using
BestComm API v2.2 20041209.
Regards,
Sal
-----Original Message-----
From: John Rigby [mailto:jcrigby@gmail.com]
Sent: Monday, June 19, 2006 2:33 PM
To: Trueskew
Cc: Andrey Volkov; linuxppc-embedded@ozlabs.org
Subject: Re: Using bestcomm in an external module (MPC5200B to be exact)
The next LTIB bsp for 5200b will use the Sylvain's bestcomm api.
On 6/19/06, Trueskew <trueskew@gmail.com> wrote:
> Hi Andrey,
>
> Thanks for the reply. I did notice that a few weeks ago and was
> waiting for the patch state to be changed from "New" to "Accepted".
> Can you give me more details on how you found out bestcomm won't be
> included in 2.6? The latest downloadable LTIB from Freescale for the
> Lite5200b includes bestcomm in several places, and the mpc52xx fec
> driver uses it, along with the ATA driver that Sylvain provided a patch
for.
>
> As for http://www.246tNt.com/mpc52xx/, it's been coming up "page not
found"
> for me for those same few weeks when I've tried it off an on, and
> www.246tNt.com just has a Welcome line in it.
>
> Sal
>
> -----Original Message-----
> From: Andrey Volkov [mailto:avolkov@varma-el.com]
> Sent: Monday, June 19, 2006 6:15 AM
> To: Trueskew
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Using bestcomm in an external module (MPC5200B to be
> exact)
>
> Trueskew wrote:
> > I should've let you all know, I'm more of a 2.4 person than a 2.6
person.
> > So I read what I could on 2.6 difference with 2.4, and it looked
> > like my easiest choice was to modify the bestcomm code to export a
> > couple tables and its API functions. I found that kallsyms has
> > almost all of the functions I needed to resolve (with 'T' next to
> > them), but they were
> still not working.
> > I added EXPORT_MODULE(TaskBDReset) and similar declarations in the
> > bestcomm api code, but that still didn't do the trick for me. So
> > what is
> the trick?
> > I think I'm on the right track, I can insmod a module that my driver
> > needs, see kallsyms get updated, and access the functions directly
> > in my driver. I hope I'm close to doing something similar with the
> > bestcomm functions, can anyone offer me some advice on what else I
> > need to
> do?
> >
> > Thanks.
> Please, check Sylvain's patchset (http://www.246tNt.com/mpc52xx/)
> _before_ you will do anithing. If be more shortly - Freescale's
> BestcommAPI _deprecated_ and will _not_ included to 2.6.xxx.
>
> --
> Regards
> Andrey Volkov
>
>
> >
> > ________________________________
> >
> > From: Trueskew [mailto:trueskew@gmail.com]
> > Sent: Friday, June 16, 2006 9:47 PM
> > To: 'linuxppc-embedded@ozlabs.org'
> > Subject: Using bestcomm in an external module (MPC5200B to be exact)
> >
> >
> > I'm writing a driver for a TI codec attached to the MPC5200B PSC3
> > codec lines on a Lite5200b. It's an external module, and I'd like
> > to use Bestcomm with it. I've already tried a bunch of horrible
> > things to
> get it to work.
> > I could say it's close, but by close I mean the FEC still runs, my
> > stuff doesn't.
> >
> > 1. Can the Bestcomm I/F be used by an external module, or is the
> > module required to be built in if built-in drivers use Bestcomm?
> > TasksInitAPI (no so bad) and TasksLoadImage (yeah, bad) aren't
> > really supposed to be called more than once from what I've read, and
> > the kernel loads them for ethernet and ATA (no disk in my system if
> > that
> matters).
> >
> > 2. If it can be used by an external module, how would I do it? I've
> > tried compiling the source into my module and replicating the
> > initialization the kernel does in addition to my own stuff. It's
> > not too bad, though I don't get any interrupts yet.
> >
> > The LTIB from Freescale includes AIC23 and AC97 drivers that use
Bestcomm.
> > I built my kernel with them set as modules, and they had the same
> > unresolved problems that my driver has on insmod, so I'm pessimistic.
> > If someone could put me out of my misery one way or another, I'd
> appreciate it.
> >
> > Thanks.
> > Sal
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [patch 07/20] spufs: fix deadlock in spu_create error path
From: Michael Ellerman @ 2006-06-20 1:16 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus, cbe-oss-dev, linux-kernel
In-Reply-To: <20060619183404.966781000@klappe.arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2487 bytes --]
On Mon, 2006-06-19 at 20:33 +0200, arnd@arndb.de wrote:
> plain text document attachment (spufs-rmdir-3.diff)
> From: Michael Ellerman <michael@ellerman.id.au>
>
> spufs_rmdir tries to acquire the spufs root
> i_mutex, which is already held by spufs_create_thread.
>
> This was tracked as Bug #H9512.
>
> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
I should have signed this off when I sent it .. but FWIW:
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>
> Index: powerpc.git/arch/powerpc/platforms/cell/spufs/inode.c
> ===================================================================
> --- powerpc.git.orig/arch/powerpc/platforms/cell/spufs/inode.c
> +++ powerpc.git/arch/powerpc/platforms/cell/spufs/inode.c
> @@ -157,20 +157,12 @@ static void spufs_prune_dir(struct dentr
> mutex_unlock(&dir->d_inode->i_mutex);
> }
>
> +/* Caller must hold root->i_mutex */
> static int spufs_rmdir(struct inode *root, struct dentry *dir_dentry)
> {
> - struct spu_context *ctx;
> -
> /* remove all entries */
> - mutex_lock(&root->i_mutex);
> spufs_prune_dir(dir_dentry);
> - mutex_unlock(&root->i_mutex);
>
> - /* We have to give up the mm_struct */
> - ctx = SPUFS_I(dir_dentry->d_inode)->i_ctx;
> - spu_forget(ctx);
> -
> - /* XXX Do we need to hold i_mutex here ? */
> return simple_rmdir(root, dir_dentry);
> }
>
> @@ -199,16 +191,23 @@ out:
>
> static int spufs_dir_close(struct inode *inode, struct file *file)
> {
> + struct spu_context *ctx;
> struct inode *dir;
> struct dentry *dentry;
> int ret;
>
> dentry = file->f_dentry;
> dir = dentry->d_parent->d_inode;
> + ctx = SPUFS_I(dentry->d_inode)->i_ctx;
>
> + mutex_lock(&dir->i_mutex);
> ret = spufs_rmdir(dir, dentry);
> + mutex_unlock(&dir->i_mutex);
> WARN_ON(ret);
>
> + /* We have to give up the mm_struct */
> + spu_forget(ctx);
> +
> return dcache_dir_close(inode, file);
> }
>
> @@ -324,8 +323,13 @@ long spufs_create_thread(struct nameidat
> * in error path of *_open().
> */
> ret = spufs_context_open(dget(dentry), mntget(nd->mnt));
> - if (ret < 0)
> - spufs_rmdir(nd->dentry->d_inode, dentry);
> + if (ret < 0) {
> + WARN_ON(spufs_rmdir(nd->dentry->d_inode, dentry));
> + mutex_unlock(&nd->dentry->d_inode->i_mutex);
> + spu_forget(SPUFS_I(dentry->d_inode)->i_ctx);
> + dput(dentry);
> + goto out;
> + }
>
> out_dput:
> dput(dentry);
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Benjamin Herrenschmidt @ 2006-06-20 1:18 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list
In-Reply-To: <40AABEB6-3467-4AFB-BC7B-08176EDD61E2@freescale.com>
> If there's precedence for it, it's fine with me. I was just curious
> about why it changed. Personally, I'd rather see it as "pic",
> because that's more specific, and it's the actual device name, but
> it's not keeping me up at night.....
I'll revert the example to "pic". I thing Segher is right, let's leave
some freedom there.
> That also works for me. I'd rather have to specify more stuff in the
> tree and have it be crystal clear how it's interpreted and used. So,
> is this true for just #address-cells, or does it affect #size-cells
> as well?
Yes. The OF spec says that #size-cells defaults to 1 when absent but I'd
rather make it mandatory. It's not used for interrupt tree resolving
though thus it's not necessary in interrupt-controller nodes.
> Sounds good. The dtc should probably throw an error (or at least a
> warning) on this, so the trees get fixed. I think I'd prefer to see
> an error - that will keep this problem from propagating any further.
Yup.
> > In the case of interrupt controllers/nexus, #address-cells is not for
> > addressable sub-nodes though but for defining the format of unit
> > interrupt specifiers for interrupt-childs which aren't necessary sub
> > nodes... confusing heh ?
>
> Um, yeah :) I think with a little clarification it will be fine,
> though.
Yeah, it's a bit complicated and I'm not that good at writing very clear
english :) I'll try to do a second pass on that part of the spec. In
fact, the only case where #address-cells is required in an interrupt
controller node (and that node is a leaf node, not also a bus), is when
an interrupt nexus points to it (that is an interrupt-map). I should
make that clear in the spec. If you don't use interrupt maps, you should
not need that #address-cells in the interrupt-controller.
Ben.
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Jon Loeliger @ 2006-06-20 3:06 UTC (permalink / raw)
To: linuxppc-dev list
In-Reply-To: <D442541A-BD06-4641-A251-3D603E32FD4F@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
> >>
> >> Yes. We should do that.
> >
> > I agree 100%.
>
> No dissenters anywhere? Please? Can't we have a fight?
There'll be no fighting in the War Room!
jdl
^ permalink raw reply
* Synch question 2.6.x
From: Srinivas Murthy @ 2006-06-20 3:10 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
Hi,
I have this 2.6.x kernel mode component for which I have question regarding
the synch reqmt. between workqueues (or tasklets) and kernel threads. The
kernel threads are created from within the kernel module and there is no
user-mode side to them.
I share some global data in the kernel space that is accessed by the kernel
thread and a work queue (or a tasklet) (kicked off of an isr top-half and
also off of a kernel thread).
Is there a need to synch access to this data if the preemption is off. What
if the premption is turned on?
In the case of workq's, if the synch is reqd, are down_xx() up_xx(),
primitives the right ones to use?
Thanks much in advance.
_Srinivas
[-- Attachment #2: Type: text/html, Size: 932 bytes --]
^ permalink raw reply
* Re: [PATCH] mpic: add support for serial mode interrupts
From: Benjamin Herrenschmidt @ 2006-06-20 4:01 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060619200811.GA15524@mag.az.mvista.com>
On Mon, 2006-06-19 at 13:08 -0700, Mark A. Greer wrote:
> MPC10x-style interrupt controllers have a serial mode that allows
> several interrupts to be clocked in through one INT signal.
>
> This patch adds the software support for that mode.
You hard code the clock ratio... why not add a separate call to be
called after mpic_init,
something like mpic_set_serial_int(int mpic, int enable, int
clock_ratio) ?
Ben.
> Signed-off-by: Mark A. Greer <mgreer@mvista.com>
> --
>
> arch/powerpc/sysdev/mpic.c | 6 ++++++
> include/asm-powerpc/mpic.h | 2 ++
> 2 files changed, 8 insertions(+)
> --
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 7dcdfcb..1829aed 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -629,6 +629,12 @@ #endif /* CONFIG_SMP */
> mb();
> }
>
> + /* For serial interrupts & set clock ratio */
> + if (flags & MPIC_SERIAL_MODE)
> + mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1,
> + mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1)
> + | (1<<27) | (0x7<<28));
> +
> /* Read feature register, calculate num CPUs and, for non-ISU
> * MPICs, num sources as well. On ISU MPICs, sources are counted
> * as ISUs are added
> diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
> index 6b9e781..f35ccdc 100644
> --- a/include/asm-powerpc/mpic.h
> +++ b/include/asm-powerpc/mpic.h
> @@ -186,6 +186,8 @@ #define MPIC_BROKEN_U3 0x00000004
> #define MPIC_BROKEN_IPI 0x00000008
> /* MPIC wants a reset */
> #define MPIC_WANTS_RESET 0x00000010
> +/* MPIC serial mode */
> +#define MPIC_SERIAL_MODE 0x00000020
>
> /* Allocate the controller structure and setup the linux irq descs
> * for the range if interrupts passed in. No HW initialization is
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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