* 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: [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
* 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: 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
* 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: [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: 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: 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: [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: 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: 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
* 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: [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
* 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: [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: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: [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: 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: [RFC] Interrupt mapping documentation
From: Jon Loeliger @ 2006-06-19 23:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Becky Bruce, linuxppc-dev list
In-Reply-To: <3E324A7E-388E-4917-B380-B0831A5F9D19@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
> > Wow, you've been busy! This mostly looks good to me - just a few
> > *minor* comments below. I've snipped out parts I'm not commenting on,
> > to shrink this email down.....
>
> Yeah. I've got some nits too, although mostly spelling. Will get to
> those later, if I find the time :-)
BTW, Becky sent him an off-list correction for a series
of spelling and grammar related changes. You might wait
for that... :-)
> 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.
>
> [...]
>
> 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! :-)
jdl
^ permalink raw reply
* Re: [PATCH] mpic: add support for Time-Of-Day-Clock (TODC)
From: Mark A. Greer @ 2006-06-19 22:45 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060619210040.GA17984@mag.az.mvista.com>
[This is a complete replacement for the earlier patch.]
The todc code from arch/ppc supports many todc/rtc chips and is needed
in arch/powerpc. This patch adds the todc code to arch/powerpc.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
arch/powerpc/Kconfig | 6
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/todc.c | 392 ++++++++++++++++++++++++++++++++++
include/asm-powerpc/todc.h | 487 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 886 insertions(+)
--
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4ef2478..39ac8fd 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -543,6 +543,12 @@ config TAU_AVERAGE
/proc/cpuinfo.
If in doubt, say N here.
+
+config PPC_TODC
+ depends on EMBEDDED6xx
+ bool "Generic Time-of-day Clock (TODC) support"
+ ---help---
+ This adds support for many TODC/RTC chips.
endmenu
source arch/powerpc/platforms/embedded6xx/Kconfig
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index cef95b0..8b0dd5f 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_PPC_83xx) += ipic.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
+obj-$(CONFIG_PPC_TODC) += todc.o
diff --git a/arch/powerpc/sysdev/todc.c b/arch/powerpc/sysdev/todc.c
new file mode 100644
index 0000000..0a65980
--- /dev/null
+++ b/arch/powerpc/sysdev/todc.c
@@ -0,0 +1,392 @@
+/*
+ * Time of Day Clock support for the M48T35, M48T37, M48T59, and MC146818
+ * Real Time Clocks/Timekeepers.
+ *
+ * Author: Mark A. Greer <mgreer@mvista.com>
+ *
+ * 2001-2004 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/time.h>
+#include <linux/timex.h>
+#include <linux/bcd.h>
+#include <linux/mc146818rtc.h>
+
+#include <asm/machdep.h>
+#include <asm/io.h>
+#include <asm/time.h>
+#include <asm/todc.h>
+
+/*
+ * Depending on the hardware on your board and your board design, the
+ * RTC/NVRAM may be accessed either directly (like normal memory) or via
+ * address/data registers. If your board uses the direct method, set
+ * 'nvram_data' to the base address of your nvram and leave 'nvram_as0' and
+ * 'nvram_as1' NULL. If your board uses address/data regs to access nvram,
+ * set 'nvram_as0' to the address of the lower byte, set 'nvram_as1' to the
+ * address of the upper byte (leave NULL if using mc146818), and set
+ * 'nvram_data' to the address of the 8-bit data register.
+ *
+ * Note: Even though the documentation for the various RTC chips say that it
+ * take up to a second before it starts updating once the 'R' bit is
+ * cleared, they always seem to update even though we bang on it many
+ * times a second. This is true, except for the Dallas Semi 1746/1747
+ * (possibly others). Those chips seem to have a real problem whenever
+ * we set the 'R' bit before reading them, they basically stop counting.
+ * --MAG
+ */
+
+/*
+ * 'todc_info' should be initialized in your *_setup.c file to
+ * point to a fully initialized 'todc_info_t' structure.
+ * This structure holds all the register offsets for your particular
+ * TODC/RTC chip.
+ * TODC_ALLOC()/TODC_INIT() will allocate and initialize this table for you.
+ */
+
+#ifdef RTC_FREQ_SELECT
+#undef RTC_FREQ_SELECT
+#define RTC_FREQ_SELECT control_b /* Register A */
+#endif
+
+#ifdef RTC_CONTROL
+#undef RTC_CONTROL
+#define RTC_CONTROL control_a /* Register B */
+#endif
+
+#ifdef RTC_INTR_FLAGS
+#undef RTC_INTR_FLAGS
+#define RTC_INTR_FLAGS watchdog /* Register C */
+#endif
+
+#ifdef RTC_VALID
+#undef RTC_VALID
+#define RTC_VALID interrupts /* Register D */
+#endif
+
+/* Access routines when RTC accessed directly (like normal memory) */
+u_char
+todc_direct_read_val(int addr)
+{
+ return readb((void __iomem *)(todc_info->nvram_data + addr));
+}
+
+void
+todc_direct_write_val(int addr, unsigned char val)
+{
+ writeb(val, (void __iomem *)(todc_info->nvram_data + addr));
+ return;
+}
+
+/* Access routines for accessing m48txx type chips via addr/data regs */
+u_char
+todc_m48txx_read_val(int addr)
+{
+ outb(addr, todc_info->nvram_as0);
+ outb(addr>>todc_info->as0_bits, todc_info->nvram_as1);
+ return inb(todc_info->nvram_data);
+}
+
+void
+todc_m48txx_write_val(int addr, unsigned char val)
+{
+ outb(addr, todc_info->nvram_as0);
+ outb(addr>>todc_info->as0_bits, todc_info->nvram_as1);
+ outb(val, todc_info->nvram_data);
+ return;
+}
+
+/* Access routines for accessing mc146818 type chips via addr/data regs */
+u_char
+todc_mc146818_read_val(int addr)
+{
+ outb_p(addr, todc_info->nvram_as0);
+ return inb_p(todc_info->nvram_data);
+}
+
+void
+todc_mc146818_write_val(int addr, unsigned char val)
+{
+ outb_p(addr, todc_info->nvram_as0);
+ outb_p(val, todc_info->nvram_data);
+}
+
+
+/*
+ * Routines to make RTC chips with NVRAM buried behind an addr/data pair
+ * have the NVRAM and clock regs appear at the same level.
+ * The NVRAM will appear to start at addr 0 and the clock regs will appear
+ * to start immediately after the NVRAM (actually, start at offset
+ * todc_info->nvram_size).
+ */
+static inline u_char
+todc_read_val(int addr)
+{
+ u_char val;
+
+ if (todc_info->sw_flags & TODC_FLAG_2_LEVEL_NVRAM) {
+ if (addr < todc_info->nvram_size) { /* NVRAM */
+ ppc_md.rtc_write_val(todc_info->nvram_addr_reg, addr);
+ val = ppc_md.rtc_read_val(todc_info->nvram_data_reg);
+ } else { /* Clock Reg */
+ addr -= todc_info->nvram_size;
+ val = ppc_md.rtc_read_val(addr);
+ }
+ } else
+ val = ppc_md.rtc_read_val(addr);
+
+ return val;
+}
+
+static inline void
+todc_write_val(int addr, u_char val)
+{
+ if (todc_info->sw_flags & TODC_FLAG_2_LEVEL_NVRAM) {
+ if (addr < todc_info->nvram_size) { /* NVRAM */
+ ppc_md.rtc_write_val(todc_info->nvram_addr_reg, addr);
+ ppc_md.rtc_write_val(todc_info->nvram_data_reg, val);
+ } else { /* Clock Reg */
+ addr -= todc_info->nvram_size;
+ ppc_md.rtc_write_val(addr, val);
+ }
+ } else
+ ppc_md.rtc_write_val(addr, val);
+}
+
+/*
+ * TODC routines
+ *
+ * There is some ugly stuff in that there are assumptions for the mc146818.
+ *
+ * Assumptions:
+ * - todc_info->control_a has the offset as mc146818 Register B reg
+ * - todc_info->control_b has the offset as mc146818 Register A reg
+ * - m48txx control reg's write enable or 'W' bit is same as
+ * mc146818 Register B 'SET' bit (i.e., 0x80)
+ *
+ * These assumptions were made to make the code simpler.
+ */
+long __init
+todc_time_init(void)
+{
+ u_char cntl_b;
+
+ if (!ppc_md.rtc_read_val)
+ ppc_md.rtc_read_val = ppc_md.nvram_read_val;
+ if (!ppc_md.rtc_write_val)
+ ppc_md.rtc_write_val = ppc_md.nvram_write_val;
+
+ cntl_b = todc_read_val(todc_info->control_b);
+
+ if (todc_info->rtc_type == TODC_TYPE_MC146818) {
+ if ((cntl_b & 0x70) != 0x20) {
+ printk(KERN_INFO "TODC real-time-clock was stopped."
+ " Now starting...");
+ cntl_b &= ~0x70;
+ cntl_b |= 0x20;
+ }
+
+ todc_write_val(todc_info->control_b, cntl_b);
+ } else if (todc_info->rtc_type == TODC_TYPE_DS17285) {
+ u_char mode;
+
+ mode = todc_read_val(TODC_TYPE_DS17285_CNTL_A);
+ /* Make sure countdown clear is not set */
+ mode &= ~0x40;
+ /* Enable oscillator, extended register set */
+ mode |= 0x30;
+ todc_write_val(TODC_TYPE_DS17285_CNTL_A, mode);
+
+ } else if (todc_info->rtc_type == TODC_TYPE_DS1501) {
+ u_char month;
+
+ todc_info->enable_read = TODC_DS1501_CNTL_B_TE;
+ todc_info->enable_write = TODC_DS1501_CNTL_B_TE;
+
+ month = todc_read_val(todc_info->month);
+
+ if ((month & 0x80) == 0x80) {
+ printk(KERN_INFO "TODC %s %s\n",
+ "real-time-clock was stopped.",
+ "Now starting...");
+ month &= ~0x80;
+ todc_write_val(todc_info->month, month);
+ }
+
+ cntl_b &= ~TODC_DS1501_CNTL_B_TE;
+ todc_write_val(todc_info->control_b, cntl_b);
+ } else { /* must be a m48txx type */
+ u_char cntl_a;
+
+ todc_info->enable_read = TODC_MK48TXX_CNTL_A_R;
+ todc_info->enable_write = TODC_MK48TXX_CNTL_A_W;
+
+ cntl_a = todc_read_val(todc_info->control_a);
+
+ /* Check & clear STOP bit in control B register */
+ if (cntl_b & TODC_MK48TXX_DAY_CB) {
+ printk(KERN_INFO "TODC %s %s\n",
+ "real-time-clock was stopped.",
+ "Now starting...");
+
+ cntl_a |= todc_info->enable_write;
+ cntl_b &= ~TODC_MK48TXX_DAY_CB;/* Start Oscil */
+
+ todc_write_val(todc_info->control_a, cntl_a);
+ todc_write_val(todc_info->control_b, cntl_b);
+ }
+
+ /* Make sure READ & WRITE bits are cleared. */
+ cntl_a &= ~(todc_info->enable_write | todc_info->enable_read);
+ todc_write_val(todc_info->control_a, cntl_a);
+ }
+
+ return 0;
+}
+
+/*
+ * There is some ugly stuff in that there are assumptions that for a mc146818,
+ * the todc_info->control_a has the offset of the mc146818 Register B reg and
+ * that the register'ss 'SET' bit is the same as the m48txx's write enable
+ * bit in the control register of the m48txx (i.e., 0x80).
+ *
+ * It was done to make the code look simpler.
+ */
+void
+todc_get_rtc_time(struct rtc_time *tm)
+{
+ uint year = 0, mon = 0, mday = 0, hour = 0, min = 0, sec = 0;
+ uint limit, i;
+ u_char save_control, uip = 0;
+ extern void GregorianDay(struct rtc_time *);
+
+ spin_lock(&rtc_lock);
+ save_control = todc_read_val(todc_info->control_a);
+
+ if (todc_info->rtc_type != TODC_TYPE_MC146818) {
+ limit = 1;
+
+ switch (todc_info->rtc_type) {
+ case TODC_TYPE_DS1553:
+ case TODC_TYPE_DS1557:
+ case TODC_TYPE_DS1743:
+ case TODC_TYPE_DS1746: /* XXXX BAD HACK -> FIX */
+ case TODC_TYPE_DS1747:
+ case TODC_TYPE_DS17285:
+ break;
+ default:
+ todc_write_val(todc_info->control_a,
+ (save_control | todc_info->enable_read));
+ }
+ } else
+ limit = 100000000;
+
+ for (i=0; i<limit; i++) {
+ if (todc_info->rtc_type == TODC_TYPE_MC146818)
+ uip = todc_read_val(todc_info->RTC_FREQ_SELECT);
+
+ sec = todc_read_val(todc_info->seconds) & 0x7f;
+ min = todc_read_val(todc_info->minutes) & 0x7f;
+ hour = todc_read_val(todc_info->hours) & 0x3f;
+ mday = todc_read_val(todc_info->day_of_month) & 0x3f;
+ mon = todc_read_val(todc_info->month) & 0x1f;
+ year = todc_read_val(todc_info->year) & 0xff;
+
+ if (todc_info->rtc_type == TODC_TYPE_MC146818) {
+ uip |= todc_read_val(todc_info->RTC_FREQ_SELECT);
+ if ((uip & RTC_UIP) == 0)
+ break;
+ }
+ }
+
+ if (todc_info->rtc_type != TODC_TYPE_MC146818) {
+ switch (todc_info->rtc_type) {
+ case TODC_TYPE_DS1553:
+ case TODC_TYPE_DS1557:
+ case TODC_TYPE_DS1743:
+ case TODC_TYPE_DS1746: /* XXXX BAD HACK -> FIX */
+ case TODC_TYPE_DS1747:
+ case TODC_TYPE_DS17285:
+ break;
+ default:
+ save_control &= ~(todc_info->enable_read);
+ todc_write_val(todc_info->control_a, save_control);
+ }
+ }
+ spin_unlock(&rtc_lock);
+
+ if ((todc_info->rtc_type != TODC_TYPE_MC146818)
+ || ((save_control & RTC_DM_BINARY) == 0)
+ || RTC_ALWAYS_BCD) {
+ BCD_TO_BIN(sec);
+ BCD_TO_BIN(min);
+ BCD_TO_BIN(hour);
+ BCD_TO_BIN(mday);
+ BCD_TO_BIN(mon);
+ BCD_TO_BIN(year);
+ }
+
+ if ((year + 1900) < 1970) {
+ year += 100;
+ }
+
+ tm->tm_sec = sec;
+ tm->tm_min = min;
+ tm->tm_hour = hour;
+ tm->tm_mday = mday;
+ tm->tm_mon = mon;
+ tm->tm_year = year;
+
+ GregorianDay(tm);
+}
+
+int
+todc_set_rtc_time(struct rtc_time *tm)
+{
+ u_char save_control, save_freq_select = 0;
+
+ spin_lock(&rtc_lock);
+ save_control = todc_read_val(todc_info->control_a);
+
+ /* Assuming MK48T59_RTC_CA_WRITE & RTC_SET are equal */
+ todc_write_val(todc_info->control_a,
+ (save_control | todc_info->enable_write));
+ save_control &= ~(todc_info->enable_write); /* in case it was set */
+
+ if (todc_info->rtc_type == TODC_TYPE_MC146818) {
+ save_freq_select = todc_read_val(todc_info->RTC_FREQ_SELECT);
+ todc_write_val(todc_info->RTC_FREQ_SELECT,
+ save_freq_select | RTC_DIV_RESET2);
+ }
+
+ if ((todc_info->rtc_type != TODC_TYPE_MC146818)
+ || ((save_control & RTC_DM_BINARY) == 0)
+ || RTC_ALWAYS_BCD) {
+ BIN_TO_BCD(tm->tm_sec);
+ BIN_TO_BCD(tm->tm_min);
+ BIN_TO_BCD(tm->tm_hour);
+ BIN_TO_BCD(tm->tm_mon);
+ BIN_TO_BCD(tm->tm_mday);
+ BIN_TO_BCD(tm->tm_year);
+ }
+
+ todc_write_val(todc_info->seconds, tm->tm_sec);
+ todc_write_val(todc_info->minutes, tm->tm_min);
+ todc_write_val(todc_info->hours, tm->tm_hour);
+ todc_write_val(todc_info->month, tm->tm_mon);
+ todc_write_val(todc_info->day_of_month, tm->tm_mday);
+ todc_write_val(todc_info->year, tm->tm_year);
+
+ todc_write_val(todc_info->control_a, save_control);
+
+ if (todc_info->rtc_type == TODC_TYPE_MC146818)
+ todc_write_val(todc_info->RTC_FREQ_SELECT, save_freq_select);
+
+ spin_unlock(&rtc_lock);
+ return 0;
+}
diff --git a/include/asm-powerpc/todc.h b/include/asm-powerpc/todc.h
new file mode 100644
index 0000000..60a8c39
--- /dev/null
+++ b/include/asm-powerpc/todc.h
@@ -0,0 +1,487 @@
+/*
+ * Definitions for the M48Txx and mc146818 series of Time of day/Real Time
+ * Clock chips.
+ *
+ * Author: Mark A. Greer <mgreer@mvista.com>
+ *
+ * 2001 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+/*
+ * Support for the M48T37/M48T59/.../mc146818 Real Time Clock chips.
+ * Purpose is to make one generic file that handles all of these chips instead
+ * of every platform implementing the same code over & over again.
+ */
+
+#ifndef __PPC_KERNEL_TODC_H
+#define __PPC_KERNEL_TODC_H
+
+typedef struct {
+ uint rtc_type; /* your particular chip */
+
+ /*
+ * Following are the addresses of the AS0, AS1, and DATA registers
+ * of these chips. Note that these are board-specific.
+ */
+ unsigned int nvram_as0;
+ unsigned int nvram_as1;
+ unsigned int nvram_data;
+
+ /*
+ * Define bits to stop external set of regs from changing so
+ * the chip can be read/written reliably.
+ */
+ unsigned char enable_read;
+ unsigned char enable_write;
+
+ /*
+ * Following is the number of AS0 address bits. This is normally
+ * 8 but some bad hardware routes address lines incorrectly.
+ */
+ int as0_bits;
+
+ int nvram_size; /* Size of NVRAM on chip */
+ int sw_flags; /* Software control flags */
+
+ /* Following are the register offsets for the particular chip */
+ int year;
+ int month;
+ int day_of_month;
+ int day_of_week;
+ int hours;
+ int minutes;
+ int seconds;
+ int control_b;
+ int control_a;
+ int watchdog;
+ int interrupts;
+ int alarm_date;
+ int alarm_hour;
+ int alarm_minutes;
+ int alarm_seconds;
+ int century;
+ int flags;
+
+ /*
+ * Some RTC chips have their NVRAM buried behind a addr/data pair of
+ * regs on the first level/clock registers. The following fields
+ * are the addresses for those addr/data regs.
+ */
+ int nvram_addr_reg;
+ int nvram_data_reg;
+} todc_info_t;
+
+/*
+ * Define the types of TODC/RTC variants that are supported in
+ * arch/ppc/kernel/todc_time.c
+ * Make a new one of these for any chip somehow differs from what's already
+ * defined. That way, if you ever need to put in code to touch those
+ * bits/registers in todc_time.c, you can put it inside an
+ * 'if (todc_info->rtc_type == TODC_TYPE_XXX)' so you won't break
+ * anyone else.
+ */
+#define TODC_TYPE_MK48T35 1
+#define TODC_TYPE_MK48T37 2
+#define TODC_TYPE_MK48T59 3
+#define TODC_TYPE_DS1693 4 /* Dallas DS1693 RTC */
+#define TODC_TYPE_DS1743 5 /* Dallas DS1743 RTC */
+#define TODC_TYPE_DS1746 6 /* Dallas DS1746 RTC */
+#define TODC_TYPE_DS1747 7 /* Dallas DS1747 RTC */
+#define TODC_TYPE_DS1501 8 /* Dallas DS1501 RTC */
+#define TODC_TYPE_DS1643 9 /* Dallas DS1643 RTC */
+#define TODC_TYPE_PC97307 10 /* PC97307 internal RTC */
+#define TODC_TYPE_DS1557 11 /* Dallas DS1557 RTC */
+#define TODC_TYPE_DS17285 12 /* Dallas DS17285 RTC */
+#define TODC_TYPE_DS1553 13 /* Dallas DS1553 RTC */
+#define TODC_TYPE_MC146818 100 /* Leave room for m48txx's */
+
+/*
+ * Bit to clear/set to enable reads/writes to the chip
+ */
+#define TODC_MK48TXX_CNTL_A_R 0x40
+#define TODC_MK48TXX_CNTL_A_W 0x80
+#define TODC_MK48TXX_DAY_CB 0x80
+
+#define TODC_DS1501_CNTL_B_TE 0x80
+
+/*
+ * Define flag bits used by todc routines.
+ */
+#define TODC_FLAG_2_LEVEL_NVRAM 0x00000001
+
+/*
+ * Define the values for the various RTC's that should to into the todc_info
+ * table.
+ * Note: The XXX_NVRAM_SIZE, XXX_NVRAM_ADDR_REG, and XXX_NVRAM_DATA_REG only
+ * matter if XXX_SW_FLAGS has TODC_FLAG_2_LEVEL_NVRAM set.
+ */
+#define TODC_TYPE_MK48T35_NVRAM_SIZE 0x7ff8
+#define TODC_TYPE_MK48T35_SW_FLAGS 0
+#define TODC_TYPE_MK48T35_YEAR 0x7fff
+#define TODC_TYPE_MK48T35_MONTH 0x7ffe
+#define TODC_TYPE_MK48T35_DOM 0x7ffd /* Day of Month */
+#define TODC_TYPE_MK48T35_DOW 0x7ffc /* Day of Week */
+#define TODC_TYPE_MK48T35_HOURS 0x7ffb
+#define TODC_TYPE_MK48T35_MINUTES 0x7ffa
+#define TODC_TYPE_MK48T35_SECONDS 0x7ff9
+#define TODC_TYPE_MK48T35_CNTL_B 0x7ff9
+#define TODC_TYPE_MK48T35_CNTL_A 0x7ff8
+#define TODC_TYPE_MK48T35_WATCHDOG 0x0000
+#define TODC_TYPE_MK48T35_INTERRUPTS 0x0000
+#define TODC_TYPE_MK48T35_ALARM_DATE 0x0000
+#define TODC_TYPE_MK48T35_ALARM_HOUR 0x0000
+#define TODC_TYPE_MK48T35_ALARM_MINUTES 0x0000
+#define TODC_TYPE_MK48T35_ALARM_SECONDS 0x0000
+#define TODC_TYPE_MK48T35_CENTURY 0x0000
+#define TODC_TYPE_MK48T35_FLAGS 0x0000
+#define TODC_TYPE_MK48T35_NVRAM_ADDR_REG 0
+#define TODC_TYPE_MK48T35_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_MK48T37_NVRAM_SIZE 0x7ff0
+#define TODC_TYPE_MK48T37_SW_FLAGS 0
+#define TODC_TYPE_MK48T37_YEAR 0x7fff
+#define TODC_TYPE_MK48T37_MONTH 0x7ffe
+#define TODC_TYPE_MK48T37_DOM 0x7ffd /* Day of Month */
+#define TODC_TYPE_MK48T37_DOW 0x7ffc /* Day of Week */
+#define TODC_TYPE_MK48T37_HOURS 0x7ffb
+#define TODC_TYPE_MK48T37_MINUTES 0x7ffa
+#define TODC_TYPE_MK48T37_SECONDS 0x7ff9
+#define TODC_TYPE_MK48T37_CNTL_B 0x7ff9
+#define TODC_TYPE_MK48T37_CNTL_A 0x7ff8
+#define TODC_TYPE_MK48T37_WATCHDOG 0x7ff7
+#define TODC_TYPE_MK48T37_INTERRUPTS 0x7ff6
+#define TODC_TYPE_MK48T37_ALARM_DATE 0x7ff5
+#define TODC_TYPE_MK48T37_ALARM_HOUR 0x7ff4
+#define TODC_TYPE_MK48T37_ALARM_MINUTES 0x7ff3
+#define TODC_TYPE_MK48T37_ALARM_SECONDS 0x7ff2
+#define TODC_TYPE_MK48T37_CENTURY 0x7ff1
+#define TODC_TYPE_MK48T37_FLAGS 0x7ff0
+#define TODC_TYPE_MK48T37_NVRAM_ADDR_REG 0
+#define TODC_TYPE_MK48T37_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_MK48T59_NVRAM_SIZE 0x1ff0
+#define TODC_TYPE_MK48T59_SW_FLAGS 0
+#define TODC_TYPE_MK48T59_YEAR 0x1fff
+#define TODC_TYPE_MK48T59_MONTH 0x1ffe
+#define TODC_TYPE_MK48T59_DOM 0x1ffd /* Day of Month */
+#define TODC_TYPE_MK48T59_DOW 0x1ffc /* Day of Week */
+#define TODC_TYPE_MK48T59_HOURS 0x1ffb
+#define TODC_TYPE_MK48T59_MINUTES 0x1ffa
+#define TODC_TYPE_MK48T59_SECONDS 0x1ff9
+#define TODC_TYPE_MK48T59_CNTL_B 0x1ff9
+#define TODC_TYPE_MK48T59_CNTL_A 0x1ff8
+#define TODC_TYPE_MK48T59_WATCHDOG 0x1fff
+#define TODC_TYPE_MK48T59_INTERRUPTS 0x1fff
+#define TODC_TYPE_MK48T59_ALARM_DATE 0x1fff
+#define TODC_TYPE_MK48T59_ALARM_HOUR 0x1fff
+#define TODC_TYPE_MK48T59_ALARM_MINUTES 0x1fff
+#define TODC_TYPE_MK48T59_ALARM_SECONDS 0x1fff
+#define TODC_TYPE_MK48T59_CENTURY 0x1fff
+#define TODC_TYPE_MK48T59_FLAGS 0x1fff
+#define TODC_TYPE_MK48T59_NVRAM_ADDR_REG 0
+#define TODC_TYPE_MK48T59_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_DS1501_NVRAM_SIZE 0x100
+#define TODC_TYPE_DS1501_SW_FLAGS TODC_FLAG_2_LEVEL_NVRAM
+#define TODC_TYPE_DS1501_YEAR (TODC_TYPE_DS1501_NVRAM_SIZE + 0x06)
+#define TODC_TYPE_DS1501_MONTH (TODC_TYPE_DS1501_NVRAM_SIZE + 0x05)
+#define TODC_TYPE_DS1501_DOM (TODC_TYPE_DS1501_NVRAM_SIZE + 0x04)
+#define TODC_TYPE_DS1501_DOW (TODC_TYPE_DS1501_NVRAM_SIZE + 0x03)
+#define TODC_TYPE_DS1501_HOURS (TODC_TYPE_DS1501_NVRAM_SIZE + 0x02)
+#define TODC_TYPE_DS1501_MINUTES (TODC_TYPE_DS1501_NVRAM_SIZE + 0x01)
+#define TODC_TYPE_DS1501_SECONDS (TODC_TYPE_DS1501_NVRAM_SIZE + 0x00)
+#define TODC_TYPE_DS1501_CNTL_B (TODC_TYPE_DS1501_NVRAM_SIZE + 0x0f)
+#define TODC_TYPE_DS1501_CNTL_A (TODC_TYPE_DS1501_NVRAM_SIZE + 0x0f)
+#define TODC_TYPE_DS1501_WATCHDOG (TODC_TYPE_DS1501_NVRAM_SIZE + 0xff)
+#define TODC_TYPE_DS1501_INTERRUPTS (TODC_TYPE_DS1501_NVRAM_SIZE + 0xff)
+#define TODC_TYPE_DS1501_ALARM_DATE (TODC_TYPE_DS1501_NVRAM_SIZE + 0x0b)
+#define TODC_TYPE_DS1501_ALARM_HOUR (TODC_TYPE_DS1501_NVRAM_SIZE + 0x0a)
+#define TODC_TYPE_DS1501_ALARM_MINUTES (TODC_TYPE_DS1501_NVRAM_SIZE + 0x09)
+#define TODC_TYPE_DS1501_ALARM_SECONDS (TODC_TYPE_DS1501_NVRAM_SIZE + 0x08)
+#define TODC_TYPE_DS1501_CENTURY (TODC_TYPE_DS1501_NVRAM_SIZE + 0x07)
+#define TODC_TYPE_DS1501_FLAGS (TODC_TYPE_DS1501_NVRAM_SIZE + 0xff)
+#define TODC_TYPE_DS1501_NVRAM_ADDR_REG 0x10
+#define TODC_TYPE_DS1501_NVRAM_DATA_REG 0x13
+
+#define TODC_TYPE_DS1553_NVRAM_SIZE 0x1ff0
+#define TODC_TYPE_DS1553_SW_FLAGS 0
+#define TODC_TYPE_DS1553_YEAR 0x1fff
+#define TODC_TYPE_DS1553_MONTH 0x1ffe
+#define TODC_TYPE_DS1553_DOM 0x1ffd /* Day of Month */
+#define TODC_TYPE_DS1553_DOW 0x1ffc /* Day of Week */
+#define TODC_TYPE_DS1553_HOURS 0x1ffb
+#define TODC_TYPE_DS1553_MINUTES 0x1ffa
+#define TODC_TYPE_DS1553_SECONDS 0x1ff9
+#define TODC_TYPE_DS1553_CNTL_B 0x1ff9
+#define TODC_TYPE_DS1553_CNTL_A 0x1ff8 /* control_a R/W regs */
+#define TODC_TYPE_DS1553_WATCHDOG 0x1ff7
+#define TODC_TYPE_DS1553_INTERRUPTS 0x1ff6
+#define TODC_TYPE_DS1553_ALARM_DATE 0x1ff5
+#define TODC_TYPE_DS1553_ALARM_HOUR 0x1ff4
+#define TODC_TYPE_DS1553_ALARM_MINUTES 0x1ff3
+#define TODC_TYPE_DS1553_ALARM_SECONDS 0x1ff2
+#define TODC_TYPE_DS1553_CENTURY 0x1ff8
+#define TODC_TYPE_DS1553_FLAGS 0x1ff0
+#define TODC_TYPE_DS1553_NVRAM_ADDR_REG 0
+#define TODC_TYPE_DS1553_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_DS1557_NVRAM_SIZE 0x7fff0
+#define TODC_TYPE_DS1557_SW_FLAGS 0
+#define TODC_TYPE_DS1557_YEAR 0x7ffff
+#define TODC_TYPE_DS1557_MONTH 0x7fffe
+#define TODC_TYPE_DS1557_DOM 0x7fffd /* Day of Month */
+#define TODC_TYPE_DS1557_DOW 0x7fffc /* Day of Week */
+#define TODC_TYPE_DS1557_HOURS 0x7fffb
+#define TODC_TYPE_DS1557_MINUTES 0x7fffa
+#define TODC_TYPE_DS1557_SECONDS 0x7fff9
+#define TODC_TYPE_DS1557_CNTL_B 0x7fff9
+#define TODC_TYPE_DS1557_CNTL_A 0x7fff8 /* control_a R/W regs */
+#define TODC_TYPE_DS1557_WATCHDOG 0x7fff7
+#define TODC_TYPE_DS1557_INTERRUPTS 0x7fff6
+#define TODC_TYPE_DS1557_ALARM_DATE 0x7fff5
+#define TODC_TYPE_DS1557_ALARM_HOUR 0x7fff4
+#define TODC_TYPE_DS1557_ALARM_MINUTES 0x7fff3
+#define TODC_TYPE_DS1557_ALARM_SECONDS 0x7fff2
+#define TODC_TYPE_DS1557_CENTURY 0x7fff8
+#define TODC_TYPE_DS1557_FLAGS 0x7fff0
+#define TODC_TYPE_DS1557_NVRAM_ADDR_REG 0
+#define TODC_TYPE_DS1557_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_DS1643_NVRAM_SIZE 0x1ff8
+#define TODC_TYPE_DS1643_SW_FLAGS 0
+#define TODC_TYPE_DS1643_YEAR 0x1fff
+#define TODC_TYPE_DS1643_MONTH 0x1ffe
+#define TODC_TYPE_DS1643_DOM 0x1ffd /* Day of Month */
+#define TODC_TYPE_DS1643_DOW 0x1ffc /* Day of Week */
+#define TODC_TYPE_DS1643_HOURS 0x1ffb
+#define TODC_TYPE_DS1643_MINUTES 0x1ffa
+#define TODC_TYPE_DS1643_SECONDS 0x1ff9
+#define TODC_TYPE_DS1643_CNTL_B 0x1ff9
+#define TODC_TYPE_DS1643_CNTL_A 0x1ff8 /* control_a R/W regs */
+#define TODC_TYPE_DS1643_WATCHDOG 0x1fff
+#define TODC_TYPE_DS1643_INTERRUPTS 0x1fff
+#define TODC_TYPE_DS1643_ALARM_DATE 0x1fff
+#define TODC_TYPE_DS1643_ALARM_HOUR 0x1fff
+#define TODC_TYPE_DS1643_ALARM_MINUTES 0x1fff
+#define TODC_TYPE_DS1643_ALARM_SECONDS 0x1fff
+#define TODC_TYPE_DS1643_CENTURY 0x1ff8
+#define TODC_TYPE_DS1643_FLAGS 0x1fff
+#define TODC_TYPE_DS1643_NVRAM_ADDR_REG 0
+#define TODC_TYPE_DS1643_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_DS1693_NVRAM_SIZE 0 /* Not handled yet */
+#define TODC_TYPE_DS1693_SW_FLAGS 0
+#define TODC_TYPE_DS1693_YEAR 0x09
+#define TODC_TYPE_DS1693_MONTH 0x08
+#define TODC_TYPE_DS1693_DOM 0x07 /* Day of Month */
+#define TODC_TYPE_DS1693_DOW 0x06 /* Day of Week */
+#define TODC_TYPE_DS1693_HOURS 0x04
+#define TODC_TYPE_DS1693_MINUTES 0x02
+#define TODC_TYPE_DS1693_SECONDS 0x00
+#define TODC_TYPE_DS1693_CNTL_B 0x0b
+#define TODC_TYPE_DS1693_CNTL_A 0x0a
+#define TODC_TYPE_DS1693_WATCHDOG 0xff
+#define TODC_TYPE_DS1693_INTERRUPTS 0xff
+#define TODC_TYPE_DS1693_ALARM_DATE 0x49
+#define TODC_TYPE_DS1693_ALARM_HOUR 0x05
+#define TODC_TYPE_DS1693_ALARM_MINUTES 0x03
+#define TODC_TYPE_DS1693_ALARM_SECONDS 0x01
+#define TODC_TYPE_DS1693_CENTURY 0x48
+#define TODC_TYPE_DS1693_FLAGS 0xff
+#define TODC_TYPE_DS1693_NVRAM_ADDR_REG 0
+#define TODC_TYPE_DS1693_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_DS1743_NVRAM_SIZE 0x1ff8
+#define TODC_TYPE_DS1743_SW_FLAGS 0
+#define TODC_TYPE_DS1743_YEAR 0x1fff
+#define TODC_TYPE_DS1743_MONTH 0x1ffe
+#define TODC_TYPE_DS1743_DOM 0x1ffd /* Day of Month */
+#define TODC_TYPE_DS1743_DOW 0x1ffc /* Day of Week */
+#define TODC_TYPE_DS1743_HOURS 0x1ffb
+#define TODC_TYPE_DS1743_MINUTES 0x1ffa
+#define TODC_TYPE_DS1743_SECONDS 0x1ff9
+#define TODC_TYPE_DS1743_CNTL_B 0x1ff9
+#define TODC_TYPE_DS1743_CNTL_A 0x1ff8 /* control_a R/W regs */
+#define TODC_TYPE_DS1743_WATCHDOG 0x1fff
+#define TODC_TYPE_DS1743_INTERRUPTS 0x1fff
+#define TODC_TYPE_DS1743_ALARM_DATE 0x1fff
+#define TODC_TYPE_DS1743_ALARM_HOUR 0x1fff
+#define TODC_TYPE_DS1743_ALARM_MINUTES 0x1fff
+#define TODC_TYPE_DS1743_ALARM_SECONDS 0x1fff
+#define TODC_TYPE_DS1743_CENTURY 0x1ff8
+#define TODC_TYPE_DS1743_FLAGS 0x1fff
+#define TODC_TYPE_DS1743_NVRAM_ADDR_REG 0
+#define TODC_TYPE_DS1743_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_DS1746_NVRAM_SIZE 0x1fff8
+#define TODC_TYPE_DS1746_SW_FLAGS 0
+#define TODC_TYPE_DS1746_YEAR 0x1ffff
+#define TODC_TYPE_DS1746_MONTH 0x1fffe
+#define TODC_TYPE_DS1746_DOM 0x1fffd /* Day of Month */
+#define TODC_TYPE_DS1746_DOW 0x1fffc /* Day of Week */
+#define TODC_TYPE_DS1746_HOURS 0x1fffb
+#define TODC_TYPE_DS1746_MINUTES 0x1fffa
+#define TODC_TYPE_DS1746_SECONDS 0x1fff9
+#define TODC_TYPE_DS1746_CNTL_B 0x1fff9
+#define TODC_TYPE_DS1746_CNTL_A 0x1fff8 /* control_a R/W regs */
+#define TODC_TYPE_DS1746_WATCHDOG 0x00000
+#define TODC_TYPE_DS1746_INTERRUPTS 0x00000
+#define TODC_TYPE_DS1746_ALARM_DATE 0x00000
+#define TODC_TYPE_DS1746_ALARM_HOUR 0x00000
+#define TODC_TYPE_DS1746_ALARM_MINUTES 0x00000
+#define TODC_TYPE_DS1746_ALARM_SECONDS 0x00000
+#define TODC_TYPE_DS1746_CENTURY 0x00000
+#define TODC_TYPE_DS1746_FLAGS 0x00000
+#define TODC_TYPE_DS1746_NVRAM_ADDR_REG 0
+#define TODC_TYPE_DS1746_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_DS1747_NVRAM_SIZE 0x7fff8
+#define TODC_TYPE_DS1747_SW_FLAGS 0
+#define TODC_TYPE_DS1747_YEAR 0x7ffff
+#define TODC_TYPE_DS1747_MONTH 0x7fffe
+#define TODC_TYPE_DS1747_DOM 0x7fffd /* Day of Month */
+#define TODC_TYPE_DS1747_DOW 0x7fffc /* Day of Week */
+#define TODC_TYPE_DS1747_HOURS 0x7fffb
+#define TODC_TYPE_DS1747_MINUTES 0x7fffa
+#define TODC_TYPE_DS1747_SECONDS 0x7fff9
+#define TODC_TYPE_DS1747_CNTL_B 0x7fff9
+#define TODC_TYPE_DS1747_CNTL_A 0x7fff8 /* control_a R/W regs */
+#define TODC_TYPE_DS1747_WATCHDOG 0x00000
+#define TODC_TYPE_DS1747_INTERRUPTS 0x00000
+#define TODC_TYPE_DS1747_ALARM_DATE 0x00000
+#define TODC_TYPE_DS1747_ALARM_HOUR 0x00000
+#define TODC_TYPE_DS1747_ALARM_MINUTES 0x00000
+#define TODC_TYPE_DS1747_ALARM_SECONDS 0x00000
+#define TODC_TYPE_DS1747_CENTURY 0x00000
+#define TODC_TYPE_DS1747_FLAGS 0x00000
+#define TODC_TYPE_DS1747_NVRAM_ADDR_REG 0
+#define TODC_TYPE_DS1747_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_DS17285_NVRAM_SIZE (0x1000-0x80) /* 4Kx8 NVRAM (minus RTC regs) */
+#define TODC_TYPE_DS17285_SW_FLAGS TODC_FLAG_2_LEVEL_NVRAM
+#define TODC_TYPE_DS17285_SECONDS (TODC_TYPE_DS17285_NVRAM_SIZE + 0x00)
+#define TODC_TYPE_DS17285_ALARM_SECONDS (TODC_TYPE_DS17285_NVRAM_SIZE + 0x01)
+#define TODC_TYPE_DS17285_MINUTES (TODC_TYPE_DS17285_NVRAM_SIZE + 0x02)
+#define TODC_TYPE_DS17285_ALARM_MINUTES (TODC_TYPE_DS17285_NVRAM_SIZE + 0x03)
+#define TODC_TYPE_DS17285_HOURS (TODC_TYPE_DS17285_NVRAM_SIZE + 0x04)
+#define TODC_TYPE_DS17285_ALARM_HOUR (TODC_TYPE_DS17285_NVRAM_SIZE + 0x05)
+#define TODC_TYPE_DS17285_DOW (TODC_TYPE_DS17285_NVRAM_SIZE + 0x06)
+#define TODC_TYPE_DS17285_DOM (TODC_TYPE_DS17285_NVRAM_SIZE + 0x07)
+#define TODC_TYPE_DS17285_MONTH (TODC_TYPE_DS17285_NVRAM_SIZE + 0x08)
+#define TODC_TYPE_DS17285_YEAR (TODC_TYPE_DS17285_NVRAM_SIZE + 0x09)
+#define TODC_TYPE_DS17285_CNTL_A (TODC_TYPE_DS17285_NVRAM_SIZE + 0x0A)
+#define TODC_TYPE_DS17285_CNTL_B (TODC_TYPE_DS17285_NVRAM_SIZE + 0x0B)
+#define TODC_TYPE_DS17285_CNTL_C (TODC_TYPE_DS17285_NVRAM_SIZE + 0x0C)
+#define TODC_TYPE_DS17285_CNTL_D (TODC_TYPE_DS17285_NVRAM_SIZE + 0x0D)
+#define TODC_TYPE_DS17285_WATCHDOG 0
+#define TODC_TYPE_DS17285_INTERRUPTS 0
+#define TODC_TYPE_DS17285_ALARM_DATE 0
+#define TODC_TYPE_DS17285_CENTURY 0
+#define TODC_TYPE_DS17285_FLAGS 0
+#define TODC_TYPE_DS17285_NVRAM_ADDR_REG 0x50
+#define TODC_TYPE_DS17285_NVRAM_DATA_REG 0x53
+
+#define TODC_TYPE_MC146818_NVRAM_SIZE 0 /* XXXX */
+#define TODC_TYPE_MC146818_SW_FLAGS 0
+#define TODC_TYPE_MC146818_YEAR 0x09
+#define TODC_TYPE_MC146818_MONTH 0x08
+#define TODC_TYPE_MC146818_DOM 0x07 /* Day of Month */
+#define TODC_TYPE_MC146818_DOW 0x06 /* Day of Week */
+#define TODC_TYPE_MC146818_HOURS 0x04
+#define TODC_TYPE_MC146818_MINUTES 0x02
+#define TODC_TYPE_MC146818_SECONDS 0x00
+#define TODC_TYPE_MC146818_CNTL_B 0x0a
+#define TODC_TYPE_MC146818_CNTL_A 0x0b /* control_a R/W regs */
+#define TODC_TYPE_MC146818_WATCHDOG 0
+#define TODC_TYPE_MC146818_INTERRUPTS 0x0c
+#define TODC_TYPE_MC146818_ALARM_DATE 0xff
+#define TODC_TYPE_MC146818_ALARM_HOUR 0x05
+#define TODC_TYPE_MC146818_ALARM_MINUTES 0x03
+#define TODC_TYPE_MC146818_ALARM_SECONDS 0x01
+#define TODC_TYPE_MC146818_CENTURY 0xff
+#define TODC_TYPE_MC146818_FLAGS 0xff
+#define TODC_TYPE_MC146818_NVRAM_ADDR_REG 0
+#define TODC_TYPE_MC146818_NVRAM_DATA_REG 0
+
+#define TODC_TYPE_PC97307_NVRAM_SIZE 0 /* No NVRAM? */
+#define TODC_TYPE_PC97307_SW_FLAGS 0
+#define TODC_TYPE_PC97307_YEAR 0x09
+#define TODC_TYPE_PC97307_MONTH 0x08
+#define TODC_TYPE_PC97307_DOM 0x07 /* Day of Month */
+#define TODC_TYPE_PC97307_DOW 0x06 /* Day of Week */
+#define TODC_TYPE_PC97307_HOURS 0x04
+#define TODC_TYPE_PC97307_MINUTES 0x02
+#define TODC_TYPE_PC97307_SECONDS 0x00
+#define TODC_TYPE_PC97307_CNTL_B 0x0a
+#define TODC_TYPE_PC97307_CNTL_A 0x0b /* control_a R/W regs */
+#define TODC_TYPE_PC97307_WATCHDOG 0x0c
+#define TODC_TYPE_PC97307_INTERRUPTS 0x0d
+#define TODC_TYPE_PC97307_ALARM_DATE 0xff
+#define TODC_TYPE_PC97307_ALARM_HOUR 0x05
+#define TODC_TYPE_PC97307_ALARM_MINUTES 0x03
+#define TODC_TYPE_PC97307_ALARM_SECONDS 0x01
+#define TODC_TYPE_PC97307_CENTURY 0xff
+#define TODC_TYPE_PC97307_FLAGS 0xff
+#define TODC_TYPE_PC97307_NVRAM_ADDR_REG 0
+#define TODC_TYPE_PC97307_NVRAM_DATA_REG 0
+
+/*
+ * Define macros to allocate and init the todc_info_t table that will
+ * be used by the todc_time.c routines.
+ */
+#define TODC_ALLOC() \
+ static todc_info_t todc_info_alloc; \
+ todc_info_t *todc_info = &todc_info_alloc;
+
+#define TODC_INIT(clock_type, as0, as1, data, bits) { \
+ todc_info->rtc_type = clock_type; \
+ \
+ todc_info->nvram_as0 = (unsigned int)(as0); \
+ todc_info->nvram_as1 = (unsigned int)(as1); \
+ todc_info->nvram_data = (unsigned int)(data); \
+ \
+ todc_info->as0_bits = (bits); \
+ \
+ todc_info->nvram_size = clock_type ##_NVRAM_SIZE; \
+ todc_info->sw_flags = clock_type ##_SW_FLAGS; \
+ \
+ todc_info->year = clock_type ##_YEAR; \
+ todc_info->month = clock_type ##_MONTH; \
+ todc_info->day_of_month = clock_type ##_DOM; \
+ todc_info->day_of_week = clock_type ##_DOW; \
+ todc_info->hours = clock_type ##_HOURS; \
+ todc_info->minutes = clock_type ##_MINUTES; \
+ todc_info->seconds = clock_type ##_SECONDS; \
+ todc_info->control_b = clock_type ##_CNTL_B; \
+ todc_info->control_a = clock_type ##_CNTL_A; \
+ todc_info->watchdog = clock_type ##_WATCHDOG; \
+ todc_info->interrupts = clock_type ##_INTERRUPTS; \
+ todc_info->alarm_date = clock_type ##_ALARM_DATE; \
+ todc_info->alarm_hour = clock_type ##_ALARM_HOUR; \
+ todc_info->alarm_minutes = clock_type ##_ALARM_MINUTES; \
+ todc_info->alarm_seconds = clock_type ##_ALARM_SECONDS; \
+ todc_info->century = clock_type ##_CENTURY; \
+ todc_info->flags = clock_type ##_FLAGS; \
+ \
+ todc_info->nvram_addr_reg = clock_type ##_NVRAM_ADDR_REG; \
+ todc_info->nvram_data_reg = clock_type ##_NVRAM_DATA_REG; \
+}
+
+extern todc_info_t *todc_info;
+
+unsigned char todc_direct_read_val(int addr);
+void todc_direct_write_val(int addr, unsigned char val);
+unsigned char todc_m48txx_read_val(int addr);
+void todc_m48txx_write_val(int addr, unsigned char val);
+unsigned char todc_mc146818_read_val(int addr);
+void todc_mc146818_write_val(int addr, unsigned char val);
+
+long todc_time_init(void);
+void todc_get_rtc_time(struct rtc_time *);
+int todc_set_rtc_time(struct rtc_time *);
+void todc_calibrate_decr(void);
+
+#endif /* __PPC_KERNEL_TODC_H */
^ permalink raw reply related
* Re: [PATCH 5/9 v3] Add the MPC8641 HPCN platform files.
From: Segher Boessenkool @ 2006-06-19 22:44 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FsSOB-0000CE-2o@jdl.com>
>> Btw, IMNSHO, it should be the firmware's job to synchronise
>> the timebases, even before the kernel gets started; at least
>> as the default. We don't want to have millions of separate
>> GPIO thingies, one for every board, unless really necessary,
>> I think?
>
> The second CPU isn't even running in the firmware.
> It is in hard-reset until Linux says "Hey, start that
> secondary CPU for me!".
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.
On other boards, all CPUs are always running (not a desirable
situation, but outside of our control, heh).
In either case, the knowledge about how to sync the timebases
more properly belongs in the firmware than in the kernel. 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?
Segher
^ permalink raw reply
* Re: [PATCH 5/9 v3] Add the MPC8641 HPCN platform files.
From: Jon Loeliger @ 2006-06-19 22:38 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <F34E213C-B073-4D85-A323-644340E3C09D@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
>
> Btw, IMNSHO, it should be the firmware's job to synchronise
> the timebases, even before the kernel gets started; at least
> as the default. We don't want to have millions of separate
> GPIO thingies, one for every board, unless really necessary,
> I think?
The second CPU isn't even running in the firmware.
It is in hard-reset until Linux says "Hey, start that
secondary CPU for me!".
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] mpic: add support for serial mode interrupts
From: Segher Boessenkool @ 2006-06-19 22:35 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060619201121.GC4845@pb15.lixom.net>
> Can you define some constants so others can see just what the bits
> mean
> without digging up documentation, instead of just doing magic numbers?
[my favourite argument :-) ]
You'll have to read the documentation to properly understand what
the bit patterns mean anyway. And if you use symbolic names, you
only add another step: hunting through header files.
> MPIC_GREG_GLOBAL_CONF_0 already does so; you can copy the style from
> there.
...but yeah, definitely, mixing styles is at least as bad.
Segher
^ permalink raw reply
* Re: [PATCH] mpic: add support for Time-Of-Day-Clock (TODC)
From: Mark A. Greer @ 2006-06-19 22:28 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1150751881.31303.87.camel@basalt.austin.ibm.com>
On Mon, Jun 19, 2006 at 04:18:00PM -0500, Hollis Blanchard wrote:
> On Mon, 2006-06-19 at 14:00 -0700, Mark A. Greer wrote:
> >
> > + * In order to break the assumption that the RTC and NVRAM are accessed by
> > + * the same mechanism, you need to explicitly set 'ppc_md.rtc_read_val' and
> > + * 'ppc_md.rtc_write_val', otherwise the values of 'ppc_md.rtc_read_val'
> > + * and 'ppc_md.rtc_write_val' will be used.
>
> I'm guessing the second references should be "nvram_read/write_val"
> instead.
Hrm, yeah, the sentence would make sense then.
I'll repost the patch.
Mark
^ permalink raw reply
* Re: [RFC] Interrupt mapping documentation
From: Segher Boessenkool @ 2006-06-19 22:22 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list
In-Reply-To: <EC61A880-9242-4BCE-B72D-8AFC038CD592@freescale.com>
> Wow, you've been busy! This mostly looks good to me - just a few
> *minor* comments below. I've snipped out parts I'm not commenting on,
> to shrink this email down.....
Yeah. I've got some nits too, although mostly spelling. Will get to
those later, if I find the time :-)
> 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.
>
> 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 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 :-)
> 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?
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.
> "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).
> 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.
> 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...
> 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.
Segher
^ 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