* solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-12-03 16:09 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <47541D70.2040805@anagramm.de>
Hello, Olof!
Clemens Koller schrieb:
> Hi, Alessandro, Hi, Olof!
>
> Olof Johansson wrote:
> > ds1307 requires you to register i2c_board_info for it to probe properly.
> > Does your platform do so?
>
> I started to add some pr_debug()s. It seems that rtc-ds1307's ds1307_init()
> is just never called despite the module gets loaded.
Finally, it works! *sigh* - Thank your for your hint to i2c_board_info!
My platform includes i2c_board_info with some i2c-devices but only uses them
if the device-tree includes the devices.
[OT+sarcasm on]
So, the time is over, where you just enable a driver in the kernel config and
the device gets probed and - if it's probed successfully - it usually works.
Now, the way is like this:
- enable the desired driver in the kernel.
- check that the platform driver fsl_soc.c (in my case) defines the
desired rtc-chip in the i2c_board_info
- check that the rtc is included in the device tree.
- embed the device tree to the kernel (cuImage)
- boot'n'pray.
That looks really groundbreaking!
Now, I cannot use one kernel for two almost identical hardware revisions
anymore because the rtc's on i2c are different? This must be a joke!
It seems like I first need to have full device tree support included in
the boot-loader to be able to duplicate my configuration work to allow
one kernel to boot on both hardware. Hmmm... this just s****!
[OT+sarcasm off]
Thank you,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Bartlomiej Sieka @ 2007-12-03 16:07 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47541D70.2040805@anagramm.de>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
Clemens Koller wrote:
> Hi, Alessandro, Hi, Olof!
>
> Olof Johansson wrote:
> > ds1307 requires you to register i2c_board_info for it to probe properly.
> > Does your platform do so?
>
> I started to add some pr_debug()s. It seems that rtc-ds1307's ds1307_init()
> is just never called despite the module gets loaded.
Hello Clemens,
Do you have rtc node in your dts file (I'm assuming arch/powerpc
situation)? If not, you'll have to add it - for example similarly to
what's being done in the attached patch (68 is the I2C address of the
RTC chip - a DS1339 in my case).
HTH,
Bartlomiej Sieka
[-- Attachment #2: motionpro_i2c_rtc_dts.diff --]
[-- Type: text/plain, Size: 603 bytes --]
diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
index 112279b..ab39d61 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -329,10 +329,17 @@
device_type = "i2c";
compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
cell-index = <1>;
+ #cell-size = <0>;
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
+ rtc@68 {
+ device_type = "rtc";
+ compatible = "dallas,ds1339";
+ reg = <68>;
+ };
+
};
sram@8000 {
device_type = "sram";
^ permalink raw reply related
* Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-12-03 16:38 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <475429DA.9060100@semihalf.com>
Hi, Bartlomiej!
Bartlomiej Sieka schrieb:
> Do you have rtc node in your dts file (I'm assuming arch/powerpc
> situation)? If not, you'll have to add it - for example similarly to
> what's being done in the attached patch (68 is the I2C address of the
> RTC chip - a DS1339 in my case).
Thank you also for your hint... that was indeed the problem here.
Simple but not really obvious.
Is it possible to have a maximum generic .dts configuration where the
kernel is told to include any device it propably finds?
I guess the failing reset since 2.6.22 is also just an entry in
my .dts... ?
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Scott Wood @ 2007-12-03 16:48 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47542A50.1030208@anagramm.de>
Clemens Koller wrote:
> [OT+sarcasm on]
>
> So, the time is over, where you just enable a driver in the kernel config and
> the device gets probed and - if it's probed successfully - it usually works.
The problem is the "probed successfully" bit -- i2c can't be
automatically detected like PCI can, and the probing that was being done
before was very error-prone.
Thus, there needs to be something describing what hardware is actually
there, not just what the kernel supports.
> Now, the way is like this:
>
> - enable the desired driver in the kernel.
As always.
> - check that the platform driver fsl_soc.c (in my case) defines the
> desired rtc-chip in the i2c_board_info
Once the glue code gets consolidated, it'll just be a one-time thing for
any given chip to be added to the OF I2C table.
I don't know why it was ever done in platform-specific code.
> - check that the rtc is included in the device tree.
This is the substitute for probing.
> - embed the device tree to the kernel (cuImage)
Or get it from the firmware.
> - boot'n'pray.
>
> That looks really groundbreaking!
>
> Now, I cannot use one kernel for two almost identical hardware revisions
> anymore because the rtc's on i2c are different? This must be a joke!
Not at all true. The kernel just needs to know, at runtime, what
hardware you actually have. It uses the device tree for this.
With cuImage, you're limited to one device tree in a given build, though
you can invoke the wrapper manually to create multiple images. However,
cuImage is a compatibility measure; if you use a newer u-boot with
device tree support, the tree does not need to be statically wrapped in
the kernel image.
> It seems like I first need to have full device tree support included in
> the boot-loader to be able to duplicate my configuration work to allow
> one kernel to boot on both hardware.
That's the simplest way, but not the only way. You could also have a
wrapper platform that chooses the proper device tree based on something
you detect.
> Hmmm... this just s****!
There are some growing pains, but the old method of blindly poking at
i2c addresses and hoping that the first driver to ask for a port that
something responds to is actually the right driver for that port is just
shit.
-Scott
^ permalink raw reply
* [PATCH] Generic RTC class support for ppc_md.[gs]et_rtc_time
From: David Woodhouse @ 2007-12-03 17:04 UTC (permalink / raw)
To: linuxppc-dev
It would be good to migrate the platform code to register RTC devices
directly, but for now this will make them functional enough for most
purposes...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 1e6715e..3e788b7 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -461,4 +461,12 @@ config RTC_DRV_RS5C313
help
If you say yes here you get support for the Ricoh RS5C313 RTC chips.
+config RTC_DRV_PPC
+ tristate "PowerPC machine dependent RTC support"
+ depends on PPC_MERGE
+ help
+ The PowerPC kernel has machine-specific functions for accessing
+ the RTC. This exposes that functionality through the generic RTC
+ class.
+
endif # RTC_CLASS
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 465db4d..e822e56 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -49,3 +49,4 @@ obj-$(CONFIG_RTC_DRV_TEST) += rtc-test.o
obj-$(CONFIG_RTC_DRV_V3020) += rtc-v3020.o
obj-$(CONFIG_RTC_DRV_VR41XX) += rtc-vr41xx.o
obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
+obj-$(CONFIG_RTC_DRV_PPC) += rtc-ppc.o
--- /dev/null 2007-12-03 03:08:41.854157978 +0000
+++ b/drivers/rtc/rtc-ppc.c 2007-12-03 16:56:15.000000000 +0000
@@ -0,0 +1,69 @@
+/*
+ * RTC driver for ppc_md RTC functions
+ *
+ * © 2007 Red Hat, Inc.
+ *
+ * Author: David Woodhouse <dwmw2@infradead.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/rtc.h>
+#include <linux/platform_device.h>
+#include <asm/machdep.h>
+
+static int ppc_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ ppc_md.get_rtc_time(tm);
+ return 0;
+}
+
+static int ppc_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ return ppc_md.set_rtc_time(tm);
+}
+
+static const struct rtc_class_ops ppc_rtc_ops = {
+ .set_time = ppc_rtc_set_time,
+ .read_time = ppc_rtc_read_time,
+};
+
+static struct rtc_device *rtc;
+static struct platform_device *ppc_rtc_pdev;
+
+static int __init ppc_rtc_init(void)
+{
+ if (!ppc_md.get_rtc_time || !ppc_md.set_rtc_time)
+ return -ENODEV;
+
+ ppc_rtc_pdev = platform_device_register_simple("ppc-rtc", 0, NULL, 0);
+ if (IS_ERR(ppc_rtc_pdev))
+ return PTR_ERR(ppc_rtc_pdev);
+
+ rtc = rtc_device_register("ppc_md", &ppc_rtc_pdev->dev,
+ &ppc_rtc_ops, THIS_MODULE);
+ if (IS_ERR(rtc)) {
+ platform_device_unregister(ppc_rtc_pdev);
+ return PTR_ERR(rtc);
+ }
+
+ return 0;
+}
+
+static void __exit ppc_rtc_exit(void)
+{
+ rtc_device_unregister(rtc);
+ platform_device_unregister(ppc_rtc_pdev);
+}
+
+module_init(ppc_rtc_init);
+module_exit(ppc_rtc_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("David Woodhouse <dwmw2@infradead.org>");
+MODULE_DESCRIPTION("Generic RTC class driver for PowerPC");
--
dwmw2
^ permalink raw reply related
* OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-12-03 17:41 UTC (permalink / raw)
To: Scott Wood; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47543351.2080904@freescale.com>
Hello, Scott!
Scott Wood schrieb:
> Clemens Koller wrote:
>> [OT+sarcasm on]
>>
>> So, the time is over, where you just enable a driver in the kernel
>> config and
>> the device gets probed and - if it's probed successfully - it usually
>> works.
>
> The problem is the "probed successfully" bit -- i2c can't be
> automatically detected like PCI can, and the probing that was being done
> before was very error-prone.
I think I understood the original purpose of device trees, or it's
intended advantage but don't see much of this yet.
Before (2.6.22) everything was working fine just by enabling the proper
kernel config. But in it's current implementation I primarily see the
an additional, duplicate, badly documented configuration step for
these - in my case - stupid, usually trivial to handle RTC chips.
> That's the simplest way, but not the only way. You could also have a
> wrapper platform that chooses the proper device tree based on something
> you detect.
Here is the problem:
something it detects = probing (what we planned to avoid)
something I detect = configurating (currently duplicated work).
This wrapper platform doesn't really exist yet in practice.
>> Hmmm... this just s****!
>
> There are some growing pains, but the old method of blindly poking at
> i2c addresses and hoping that the first driver to ask for a port that
> something responds to is actually the right driver for that port is just
> shit.
That's not a good example: Of course, blindly poking is bad...
therefore there is the (kernel.)configuration step to have only
the relevant drivers enabled:
The Philips PCF8563 is on address 0x51 and the DS13x7 on 0x68.
The drivers don't touch foreign addresses at all and they are
fixed. No issues there... proved by 2.6.22.
Well, I don't want to start a flamewar on this since we have had
already enough pro & contra Device Tree discussions. I just want
to point out that the current situation doesn't really follow
the KISS principle at all in my eyes.
Here, the next idea which comes to my mind:
Maybe we should think about a kernel-config -> dts compiler for
the future where the enabled drivers generate their default dts
entries automagically?
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* [PATCH] [POWERPC] Improved documentation of device tree 'ranges'.
From: Stephen Neuendorffer @ 2007-12-03 17:45 UTC (permalink / raw)
To: grant.likely, david, linuxppc-dev
I was misled by the prior language. I've attempted to clarify how
'ranges' are used, in particular, how to get a 1:1 mapping.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
Documentation/powerpc/booting-without-of.txt | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..aad8bf5 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -711,13 +711,14 @@ define a bus type with a more complex address format, including things
like address space bits, you'll have to add a bus translator to the
prom_parse.c file of the recent kernels for your bus type.
-The "reg" property only defines addresses and sizes (if #size-cells
-is non-0) within a given bus. In order to translate addresses upward
+The "reg" property only defines addresses and sizes (if #size-cells is
+non-0) within a given bus. In order to translate addresses upward
(that is into parent bus addresses, and possibly into CPU physical
addresses), all busses must contain a "ranges" property. If the
"ranges" property is missing at a given level, it's assumed that
-translation isn't possible. The format of the "ranges" property for a
-bus is a list of:
+translation isn't possible, i.e., the registers are not visible on the
+parent bus. The format of the "ranges" property for a bus is a list
+of:
bus address, parent bus address, size
@@ -735,6 +736,8 @@ fit in a single 32-bit word. New 32-bit powerpc boards should use a
1/1 format, unless the processor supports physical addresses greater
than 32-bits, in which case a 2/1 format is recommended.
+Alternatively, the "ranges" property may be empty, indicating that the
+registers are visible on the parent bus, with 1:1 address translation.
2) Note about "compatible" properties
-------------------------------------
--
1.5.3.4
^ permalink raw reply related
* Re: Maximum ioremap size for ppc arch?
From: David Hawkins @ 2007-12-03 17:50 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20071203153009.GA30746@gate.crashing.org>
Hi Matt,
> On Mon, Dec 03, 2007 at 09:22:06AM -0000, michael.firth@bt.com wrote:
>> I'm trying to get am MPC834x system running that has 256MBytes of NOR
>> flash connected.
>>
>> The physmap flash driver is failing to ioremap() that amount of space,
>> while on a similar system with 128Mbytes of flash, there are no
>> problems.
>>
>> Is this a known limitation of ioremap() on the ppc architecture, or
>> specifically the MPC834x family, and is there any (hopefully easy) way
>> to increase this limit?
>
> The answer is "it depends". It depends on the amount of system memory
> you have. By default, your system memory is mapped at 0xc0000000, leaving
> not enough space for vmalloc allocations to grab 256MB for the
> ioremap (and avoid the fixed virtual mapping in the high virtual
> address area).
>
> See the "Advanced setup" menu. Normally, you can set "Set custom kernel
> base address" to 0xa0000000 safely. That will give you an additional
> 256MB of vmalloc space. On arch/powerpc, you'll also have to set
> "Size of user task space" to 0x80000000 or 0xa0000000.
Could you comment on a similar problem I had/have.
I have a CPU with 1GB memory, and I use about 20 cPCI boards that
I give 8MB windows in PCI space. When I was trying to load my
custom driver with these boards, it would give me ioremap failures.
On a CPU that had 512MB of memory it worked fine. My 'temporary hack'
(which is still in place) for the 1GB CPUs was to add mem=512M (or
whatever it is) to the kernel command line. That was a good
enough fix at the time :)
I have figured I was running out of page table entries or something
like that and was going to investigate one of these days ...
However, perhaps it was that I was running out of address space.
But 0xC0000000 is at 3GB, I can't see that I would be triggering
an address space issue:
1GB = 0x40000000
20 x 8MB = 160MB
But, I figured I'd ask anyway :)
Thanks,
Dave
PS. The CPUs in this case are x86 based, while the PCI boards use
PLX-9054 bridges. I'm building new peripheral boards with MPC8349EAs
so this problem is going to rear its ugly head again soon, when
I work on the drivers for the new peripheral boards.
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Scott Wood @ 2007-12-03 18:07 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47543FAD.7040504@anagramm.de>
Clemens Koller wrote:
> Scott Wood schrieb:
> > The problem is the "probed successfully" bit -- i2c can't be
> > automatically detected like PCI can, and the probing that was being done
> > before was very error-prone.
>
> I think I understood the original purpose of device trees, or it's
> intended advantage but don't see much of this yet.
>
> Before (2.6.22) everything was working fine just by enabling the proper
> kernel config.
Just because it worked fine *for you* doesn't mean it worked fine in
general.
1. This means that you can't use the same kernel with different
hardware, which is precisely what you were complaining that you couldn't do.
2. What if you have two i2c devices at the same address on different
buses? Or if you have two devices, these devices can reside on a
variety of ports, and the driver for one tries to probe the port of the
other? .config doesn't help you now.
3. What if you need to pass in extra information to the driver, such as
the exact chip type when more than one is handled by the same driver, or
the IRQ line if the chip uses one, etc?
> Well, I don't want to start a flamewar on this since we have had
> already enough pro & contra Device Tree discussions. I just want
> to point out that the current situation doesn't really follow
> the KISS principle at all in my eyes.
It should be as simple as it can be and still work, but no simpler.
Before, it was too simple to work.
> Here, the next idea which comes to my mind:
> Maybe we should think about a kernel-config -> dts compiler for
> the future where the enabled drivers generate their default dts
> entries automagically?
Sorry, there's just not enough information in .config for that.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Improved documentation of device tree 'ranges'.
From: Grant Likely @ 2007-12-03 18:09 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Paul Mackerras, david
In-Reply-To: <20071203174403.C740719B0073@mail119-sin.bigfish.com>
On 12/3/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> I was misled by the prior language. I've attempted to clarify how
> 'ranges' are used, in particular, how to get a 1:1 mapping.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Documentation/powerpc/booting-without-of.txt | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..aad8bf5 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -711,13 +711,14 @@ define a bus type with a more complex address format, including things
> like address space bits, you'll have to add a bus translator to the
> prom_parse.c file of the recent kernels for your bus type.
>
> -The "reg" property only defines addresses and sizes (if #size-cells
> -is non-0) within a given bus. In order to translate addresses upward
> +The "reg" property only defines addresses and sizes (if #size-cells is
> +non-0) within a given bus. In order to translate addresses upward
> (that is into parent bus addresses, and possibly into CPU physical
> addresses), all busses must contain a "ranges" property. If the
> "ranges" property is missing at a given level, it's assumed that
> -translation isn't possible. The format of the "ranges" property for a
> -bus is a list of:
> +translation isn't possible, i.e., the registers are not visible on the
> +parent bus. The format of the "ranges" property for a bus is a list
> +of:
>
> bus address, parent bus address, size
>
> @@ -735,6 +736,8 @@ fit in a single 32-bit word. New 32-bit powerpc boards should use a
> 1/1 format, unless the processor supports physical addresses greater
> than 32-bits, in which case a 2/1 format is recommended.
>
> +Alternatively, the "ranges" property may be empty, indicating that the
> +registers are visible on the parent bus, with 1:1 address translation.
>
> 2) Note about "compatible" properties
> -------------------------------------
> --
> 1.5.3.4
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Maximum ioremap size for ppc arch?
From: Matt Porter @ 2007-12-03 19:07 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <475441DD.9030601@ovro.caltech.edu>
On Mon, Dec 03, 2007 at 09:50:21AM -0800, David Hawkins wrote:
> Could you comment on a similar problem I had/have.
>
> I have a CPU with 1GB memory, and I use about 20 cPCI boards that
> I give 8MB windows in PCI space. When I was trying to load my
> custom driver with these boards, it would give me ioremap failures.
> On a CPU that had 512MB of memory it worked fine. My 'temporary hack'
> (which is still in place) for the 1GB CPUs was to add mem=512M (or
> whatever it is) to the kernel command line. That was a good
> enough fix at the time :)
>
> I have figured I was running out of page table entries or something
> like that and was going to investigate one of these days ...
>
> However, perhaps it was that I was running out of address space.
> But 0xC0000000 is at 3GB, I can't see that I would be triggering
> an address space issue:
>
> 1GB = 0x40000000
> 20 x 8MB = 160MB
>
> But, I figured I'd ask anyway :)
Yes, same thing. There's N ways to fix it. But I see you're talking
x86.
> PS. The CPUs in this case are x86 based, while the PCI boards use
> PLX-9054 bridges. I'm building new peripheral boards with MPC8349EAs
> so this problem is going to rear its ugly head again soon, when
> I work on the drivers for the new peripheral boards.
You should be able to do something similar on x86 but the details
are TBD. I would probably try to limit low memory to 512MB in the
x86 case.
-Matt
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Jon Loeliger @ 2007-12-03 19:26 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20071203015018.GC26919@localhost.localdomain>
On Sun, 2007-12-02 at 19:50, David Gibson wrote:
> > + clock-frequency = <7f28155>; /* 133.333333 MHz */
> You can use <d# 133333333> to avoid the ugly hex.
Better still, blaze a new trail, convert it to /dts-v1/ and
use clock-frequency = <133333333> straight up!
jdl
^ permalink raw reply
* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Linas Vepstas @ 2007-12-03 19:32 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Will Schmidt, paulus
In-Reply-To: <20071129104147.GA3694@aepfle.de>
On Thu, Nov 29, 2007 at 11:41:47AM +0100, Olaf Hering wrote:
> On Wed, Nov 28, Linas Vepstas wrote:
>
> > On Wed, Nov 28, 2007 at 12:00:37PM +0100, Olaf Hering wrote:
> > > On Tue, Nov 27, Will Schmidt wrote:
>
> > > > > - if (panic_timeout)
> > > > > - return;
> > >
> > > This change is wrong. Booting with panic=123 really means the system
> > > has to reboot in 123 seconds after a panic.
> >
> > And it does.
>
> Have you ever tried it? Current state is that the JS20 hangs after
> panic,
It should printout the "Rebooting in timeout_wait seconds ..."
Then it should wait timeout_wait number of seconds, as usual,
and *then* call the hypervisor.
> simply because it calls into the hypervisor (or whatever).
The hypervisor is not supposed to return at this point. Its supposed
to reboot. Appearently, its not rebooting. Either we are using it
wrong, or the hypervisor is buggy on some systems. It did work on
the machines I was on; but I did not try power5's or blades.
> So, please restore the panic_timeout check.
The problem with this check was that was that the value was never
ever set, and so the branch was never ever taken.
--linas
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-12-03 19:35 UTC (permalink / raw)
To: Scott Wood; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <475445DF.6080202@freescale.com>
Hello, Scott!
Scott Wood schrieb:
>> Here, the next idea which comes to my mind:
>> Maybe we should think about a kernel-config -> dts compiler for
>> the future where the enabled drivers generate their default dts
>> entries automagically?
>
> Sorry, there's just not enough information in .config for that.
If there is really the need to put more information (which I don't
see in the case of the RTCs) to .config, it might be an idea to
extend the current structure for this use instead of duplicating
and maintaining a second repository.
And regarding the DS1337 (or the PCF8563 and similar RTCs):
It's address (0x68) is immutable fixed by the manufacturer
of that device. So, why do we include it in the DT, when we
already told the kernel what driver we want to use?
Even if I have an eeprom which can have varying addresses,
I can simply tell the driver/the kernel .config what address
it should use... If I want to be able to alter that address
for whatever reason by OF, I still don't want to touch a
separate file in the kernel tree.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: Maximum ioremap size for ppc arch?
From: David Hawkins @ 2007-12-03 19:51 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20071203190723.GB30746@gate.crashing.org>
Hi Matt,
> Yes, same thing. There's N ways to fix it. But I see you're talking
> x86.
>
>> PS. The CPUs in this case are x86 based, while the PCI boards use
>> PLX-9054 bridges. I'm building new peripheral boards with MPC8349EAs
>> so this problem is going to rear its ugly head again soon, when
>> I work on the drivers for the new peripheral boards.
>
> You should be able to do something similar on x86 but the details
> are TBD. I would probably try to limit low memory to 512MB in the
> x86 case.
Yeah, that works for me. The CPUs were ordered with 512MB,
but arrived with 1GB. It was thought a windfall at the time ...
but not-so after the driver weirdness :)
Thanks for the info. Now at least if I want to understand the
problem, I know where to look.
Cheers,
Dave
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Grant Likely @ 2007-12-03 20:05 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47545A81.90804@anagramm.de>
On 12/3/07, Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hello, Scott!
>
> Scott Wood schrieb:
> >> Here, the next idea which comes to my mind:
> >> Maybe we should think about a kernel-config -> dts compiler for
> >> the future where the enabled drivers generate their default dts
> >> entries automagically?
> >
> > Sorry, there's just not enough information in .config for that.
>
> If there is really the need to put more information (which I don't
> see in the case of the RTCs) to .config, it might be an idea to
> extend the current structure for this use instead of duplicating
> and maintaining a second repository.
>
> And regarding the DS1337 (or the PCF8563 and similar RTCs):
> It's address (0x68) is immutable fixed by the manufacturer
> of that device. So, why do we include it in the DT, when we
> already told the kernel what driver we want to use?
I2C is an odd bus in that it is only partially probeable; you can
probe for presence, but you can't trust that you know what is there.
The device tree approach sidesteps that uncertainty by just mandating
that you specify that address and type of each device. This is
neither hard or onerous on the developer to do.
If we *could* trust the i2c probing (like we can on PCI), then i2c
devices would *not* need to be in the device tree.
> Even if I have an eeprom which can have varying addresses,
> I can simply tell the driver/the kernel .config what address
> it should use... If I want to be able to alter that address
> for whatever reason by OF, I still don't want to touch a
> separate file in the kernel tree.
Kconfig was never designed for that type of board level detail and it
would be awkward to shoehorn that in (not to mention that it doesn't
solve the problem of one kernel running on many boards.)
Historically we solved the config problem with board specific code in
.c files. A solution I'm sure you'll agree might work, but it's not
sustainable in the long run.
As for modifying the device tree; you've got many choices; choose what
works best for you.
For example, you could:
a. write a separate .dts file per board varient, or
b. write single .dts files which only contains the common properties
and the bootloader populates the board specific ones, or
c. write a single .dts file which contains all possible nodes and the
bootloader deletes the nodes which are irrelevant.
Regardless of what method you choose, you just need to make sure that
the device tree that the kernel receives is an accurate representation
of the hardware (ie. no nodes for non-present devices)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* SMP on linux with Microblaze?
From: khollan @ 2007-12-03 20:06 UTC (permalink / raw)
To: linuxppc-embedded
Now that Full Linux can run on Microblaze with the addition of the MMU, are
there plans to enable Symmetric Multi-Processing of two or more Microblaze
cores running Linux?
--
View this message in context: http://www.nabble.com/SMP-on-linux-with-Microblaze--tf4939013.html#a14137760
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: Cannot login via tinylogin on sequoia
From: Leonid @ 2007-12-03 20:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C028D2294@ehost011-3.exch011.intermedia.net>
I can avoid login procedure at all by replacing tinylogin call by simple
sh in inittab or by removing inittab at all:
#::askfirst:/bin/tinylogin login -f root=20
::askfirst:/bin/sh
I get shell prompt all right without logging. However login doesn't work
and I don't understand why.=20
I tried to change password using passwd (user: root, password: root),
but login still doesn't work:
/ # passwd root
Changing password for root
Enter the new password (minimum of 5, maximum of 8 characters) Please
use a combination of upper and lower case letters and numbers.
Enter new password:
Re-enter new password:
Password changed.
/ # Dec 31 18:02:29 Sequoia auth.info passwd[38]: password for `root'
changed by user `root'
/ # login
Sequoia login: root
Password:
Login incorrect
Does somebody know a way to make tinylogin give out more detailed
iunformation? Of course, I can always debug it since I have source...
Thanks,
Leonid.
-----Original Message-----
From: linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org] On =
Behalf
Of Leonid
Sent: Friday, November 30, 2007 3:10 PM
To: linuxppc-embedded@ozlabs.org
Subject: Cannot login via tinylogin on sequoia
Hi:
I have built u-boot, kernel and filesystem using ELDK 4.1 for AMCC
PPC440EPx sequoia board. When I boot linux using NFS filesystem,
supplied with ELDK itself, I can login (usrr root, no password). However
I couldn't login while used ramdisk, built by myself or taken from AMCC
resource CD. Combinations root/root or root/nothing don't work.=20
Sequoia login: root
Password:
Login incorrect
Please press Enter to activate this console. Dec 31 18:00:26 Sequoia
auth.warn login[37]: invalid password for `UNKNOWN' on `ttyS0'
Dec 31 18:00:26 Sequoia daemon.info init: Process '/bin/tinylogin login
-f root' (pid 37) exited. Scheduling it for restart.
How I can learn what user/password combination are configured and how do
I change them? This is static/etc/passwd from my SIMPLE filesystem:
root::0:0:root:/root:/bin/sh
bin:*:1:1:bin:/bin:
daemon:*:2:2:daemon:/sbin:
halt:*:7:0:halt:/sbin:/sbin/halt
ftp:*:14:50:FTP User:/
nobody:*:99:99:Nobody:/:
target:$1$x4Rc1j78$n5FVlLwarSyMYoZaMlijU1:200:100:Test
User:/home:/bin/sh
Thanks,
Leonid.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] Generic RTC class support for ppc_md.[gs]et_rtc_time
From: Benjamin Herrenschmidt @ 2007-12-03 20:45 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1196701493.13978.163.camel@pmac.infradead.org>
On Mon, 2007-12-03 at 17:04 +0000, David Woodhouse wrote:
> It would be good to migrate the platform code to register RTC devices
> directly, but for now this will make them functional enough for most
> purposes...
Wouldn't it be best to do the other way around at some stage ?
We need to solve the problem of ppc_md. stuff being called by the core
in atomic contexts first though.
Ben.
^ permalink raw reply
* [PATCH] Add abort for fsl-devices which lack an RSTCR register.
From: Clemens Koller @ 2007-12-03 20:51 UTC (permalink / raw)
To: Linuxppc-embedded, Kumar Gala, robert lazarski
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
This adds a fallback and calls abort() (in head_fsl_booke.S) to be able
to successfully reset some older freescale devices (i.e. mpc8540)
which don't have a RSTCR register.
Robert, this should also fix your issues. Please test.
Kumar, please ACK/NACK the patch since you touched fsl_rstcr_restart()
last time (2007-10-04). Maybe the call to abort (which resets the processor via
the Debug Control Register 0) could be put somewhere else or
we create another entry for the device tree.
Otherwise, I would prefer to check the PVR/SVR registers and use
a suitable cpu_reset() call which fits to the current cpu.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
[-- Attachment #2: powerpc-add-abort-to-reset-systems-without-rstcr-register.patch --]
[-- Type: text/plain, Size: 883 bytes --]
Add a fallback to abort() call (in head_fsl_booke.S) to be able to
successfully reset some older freescale power devices (i.e. mpc8540)
which don't have a rstcr register.
Signed-off-by: Clemens Koller <clemens.koller@anagramm.de>
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..6fe674a 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -42,6 +42,7 @@
extern void init_fcc_ioports(struct fs_platform_info*);
extern void init_fec_ioports(struct fs_platform_info*);
extern void init_smc_ioports(struct fs_uart_platform_info*);
+extern void abort(void);
static phys_addr_t immrbase = -1;
phys_addr_t get_immrbase(void)
@@ -1336,6 +1337,8 @@ void fsl_rstcr_restart(char *cmd)
if (rstcr)
/* set reset control register */
out_be32(rstcr, 0x2); /* HRESET_REQ */
+ else
+ abort();
while (1) ;
}
^ permalink raw reply related
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Benjamin Herrenschmidt @ 2007-12-03 20:52 UTC (permalink / raw)
To: Andrei Dolnikov; +Cc: linuxppc-dev
In-Reply-To: <20071129152836.GB13751@ru.mvista.com>
> #address-cells = <1>;
> + #size-cells = <1>;
> + model = "Katana-Qp"; /* Default */
> + compatible = "emerson,Katana-Qp";
> + coherency-off;
> +
What do that mean (coherency-off) ?
Somebody is trying again to use a 74xx with non cache coherent DMA ?
That isn't going to fly...
Ben.
^ permalink raw reply
* Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
From: Benjamin Herrenschmidt @ 2007-12-03 20:54 UTC (permalink / raw)
To: Andrei Dolnikov; +Cc: linuxppc-dev
In-Reply-To: <20071129154200.GE13751@ru.mvista.com>
On Thu, 2007-11-29 at 18:42 +0300, Andrei Dolnikov wrote:
> +config PPC_KATANAQP
> + bool "Emerson-Katana Qp"
> + depends on EMBEDDED6xx
> + select MV64X60
> + select NOT_COHERENT_CACHE
^^^^^^^^^^^^^^^^^^
Just one word: ARGHHHHHHHH !
Oh and another one: WHY ?
Ben.
^ permalink raw reply
* [PATCH] Fix 8xx compile errors
From: John Tyner @ 2007-12-03 20:58 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
Building for 8xx fails to compile due to errors in a couple of places.
The first is due to the casting of an lvalue (if I remember correctly),
and the second was due to the cpmp variable being declared static even
though the headers previously defined it as extern. The following patch
corrects these errors. The patch is against 2.4 since that's what I'm
working with. (I've been unable to get 2.6 to run properly on my
hardware so far.)
Please CC me on any responses since I'm not subscribed.
Thanks,
John
[-- Attachment #2: 8xx_compile.patch --]
[-- Type: text/plain, Size: 1125 bytes --]
diff -ruNa linux-2.4.35.4.orig/arch/ppc/8xx_io/uart.c linux-2.4.35.4/arch/ppc/8xx_io/uart.c
--- linux-2.4.35.4.orig/arch/ppc/8xx_io/uart.c 2007-11-17 09:23:15.000000000 -0800
+++ linux-2.4.35.4/arch/ppc/8xx_io/uart.c 2007-11-27 11:28:09.000000000 -0800
@@ -2292,7 +2292,8 @@
/* Get the address of the host memory buffer.*/
info = &consinfo;
- info->tx_bd_base = (cbd_t *)bdbase = (cbd_t *)&cpmp->cp_dpmem[up->smc_tbase];
+ bdbase = (cbd_t *)&cpmp->cp_dpmem[up->smc_tbase];
+ info->tx_bd_base = (cbd_t *)bdbase;
info->tx_cur = (cbd_t *)bdbase;
}
max_tx_size = console_tx_buf_len;
diff -ruNa linux-2.4.35.4.orig/arch/ppc/boot/simple/m8xx_tty.c linux-2.4.35.4/arch/ppc/boot/simple/m8xx_tty.c
--- linux-2.4.35.4.orig/arch/ppc/boot/simple/m8xx_tty.c 2007-11-17 09:23:15.000000000 -0800
+++ linux-2.4.35.4/arch/ppc/boot/simple/m8xx_tty.c 2007-11-27 11:28:42.000000000 -0800
@@ -30,7 +30,7 @@
#define SMC_INDEX 0
#endif
-static cpm8xx_t *cpmp = (cpm8xx_t *)&(((immap_t *)IMAP_ADDR)->im_cpm);
+cpm8xx_t *cpmp = (cpm8xx_t *)&(((immap_t *)IMAP_ADDR)->im_cpm);
unsigned long
serial_init(int ignored, bd_t *bd)
^ permalink raw reply
* Re: [PATCH] ipic: change ack operation that register is accessed only when needed
From: Benjamin Herrenschmidt @ 2007-12-03 21:02 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1196684780-28408-1-git-send-email-leoli@freescale.com>
> static void ipic_ack_irq(unsigned int virq)
> {
> - struct ipic *ipic = ipic_from_irq(virq);
> unsigned int src = ipic_irq_to_hw(virq);
> - unsigned long flags;
> - u32 temp;
>
> - spin_lock_irqsave(&ipic_lock, flags);
> + /* Only external interrupts in edge mode support ACK */
> + if (unlikely(ipic_info[src].ack &&
> + ((get_irq_desc(virq)->status & IRQ_TYPE_SENSE_MASK) ==
> + IRQ_TYPE_EDGE_FALLING))) {
> + struct ipic *ipic = ipic_from_irq(virq);
> + unsigned long flags;
> + u32 temp;
>
> - temp = ipic_read(ipic->regs, ipic_info[src].pend);
> - temp |= (1 << (31 - ipic_info[src].bit));
> - ipic_write(ipic->regs, ipic_info[src].pend, temp);
> + spin_lock_irqsave(&ipic_lock, flags);
>
> - spin_unlock_irqrestore(&ipic_lock, flags);
> + temp = ipic_read(ipic->regs, ipic_info[src].ack);
> + temp |= (1 << (31 - ipic_info[src].bit));
> + ipic_write(ipic->regs, ipic_info[src].ack, temp);
> +
> + spin_unlock_irqrestore(&ipic_lock, flags);
> + }
> }
That doesn't look right...
That should be handled by the higher level flow handler. The generic
edge one calls ack and the level one mask_and_ack. Just make them do the
right thing, no need to test for the flow type in the low level
function.
Ben.
^ permalink raw reply
* Re: [PATCH] Add IPIC MSI interrupt support
From: Benjamin Herrenschmidt @ 2007-12-03 21:03 UTC (permalink / raw)
To: Li Li; +Cc: linuxppc-dev, Gala Kumar, Li Tony
In-Reply-To: <1196672870.14353.21.camel@Guyver>
On Mon, 2007-12-03 at 17:07 +0800, Li Li wrote:
>
> In IPIC, the 8 MSI interrupts is handled as level intrrupt.
> I just provide a versatile in case it is changed.
Level ? Are you sure ? MSIs are by definition edge interrupts... Or do
you have some weird logic that asserts a level input until you go ack
something ? Sounds weird...
Ben.
^ 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