* Re: for-2.6.23 branch in powerpc.git created
From: Paul Mackerras @ 2007-06-19 6:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <4672D694.5060701@freescale.com>
Scott Wood writes:
> Guennadi Liakhovetski wrote:
> > These two i2c patches:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
>
> This looks OK as an interim measure, though at some point I'd like to
> get around to letting both devices and drivers specify a list of match
> names.
>
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
>
> I'd leave out the device_type, and the "rtc" in "rtc-r5c372" is
> redundant if that's all the r5c372 chip does, but other than that it
> looks good.
>
> > also would be nice to get in, although, they only make sense with an ack
> > from Scott Wood and another patch from him, as explained in links above...
>
> I assume you mean "Call of_register_i2c_devices() for fsl-i2c"
> (http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036333.html)?
Isn't that the one where you replied to yourself saying you'd posted
the wrong patch? Did you ever post the right patch?
Paul.
^ permalink raw reply
* [PATCH/RFC] Modify sched_clock() to make CONFIG_PRINTK_TIME more sane.
From: Tony Breeds @ 2007-06-19 6:35 UTC (permalink / raw)
To: LinuxPPC-dev
When booting a current kernel with CONFIG_PRINTK_TIME enabled you'll
see messages like:
[ 0.000000] time_init: decrementer frequency = 188.044000 MHz
[ 0.000000] time_init: processor frequency = 1504.352000 MHz
[3712914.436297] Console: colour dummy device 80x25
This patch modifies sched_clock() to report the offset since the machine booted
so the same printk's now look like:
[ 0.000000] time_init: decrementer frequency = 188.044000 MHz
[ 0.000000] time_init: processor frequency = 1504.352000 MHz
[ 0.000135] Console: colour dummy device 80x25
Effectivly including the uptime in printk()s.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/time.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: working/arch/powerpc/kernel/time.c
===================================================================
--- working.orig/arch/powerpc/kernel/time.c
+++ working/arch/powerpc/kernel/time.c
@@ -115,6 +115,7 @@ EXPORT_SYMBOL_GPL(rtc_lock);
u64 tb_to_ns_scale;
unsigned tb_to_ns_shift;
+unsigned long boot_tb;
struct gettimeofday_struct do_gtod;
@@ -735,7 +736,7 @@ unsigned long long sched_clock(void)
{
if (__USE_RTC())
return get_rtc();
- return mulhdu(get_tb(), tb_to_ns_scale) << tb_to_ns_shift;
+ return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
}
int do_settimeofday(struct timespec *tv)
@@ -960,6 +961,8 @@ void __init time_init(void)
}
tb_to_ns_scale = scale;
tb_to_ns_shift = shift;
+ /* Save the current timebase to pretty up CONFIG_PRINTK_TIME */
+ boot_tb = get_tb();
tm = get_boot_time();
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Abolish unused ucBoardRev variables
From: David Gibson @ 2007-06-19 6:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
asm-powerpc/processor.h declares, and arch/ppc/platforms/prep_setup.c
defines variables ucBoardRev, ucBoardRevMaj and ucBoardRevMin which
are used nowhere in the current kernel (neither in arch/ppc nor
arch/powerpc). This patch removes them.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Please merge for 2.6.23
Index: working-2.6/arch/ppc/platforms/prep_setup.c
===================================================================
--- working-2.6.orig/arch/ppc/platforms/prep_setup.c 2007-06-19 16:38:20.000000000 +1000
+++ working-2.6/arch/ppc/platforms/prep_setup.c 2007-06-19 16:38:23.000000000 +1000
@@ -69,9 +69,6 @@
TODC_ALLOC();
-unsigned char ucBoardRev;
-unsigned char ucBoardRevMaj, ucBoardRevMin;
-
extern unsigned char prep_nvram_read_val(int addr);
extern void prep_nvram_write_val(int addr,
unsigned char val);
Index: working-2.6/include/asm-powerpc/processor.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/processor.h 2007-06-19 16:38:03.000000000 +1000
+++ working-2.6/include/asm-powerpc/processor.h 2007-06-19 16:38:09.000000000 +1000
@@ -43,14 +43,6 @@ extern int _chrp_type;
/* what kind of prep workstation we are */
extern int _prep_type;
-/*
- * This is used to identify the board type from a given PReP board
- * vendor. Board revision is also made available. This will be moved
- * elsewhere soon
- */
-extern unsigned char ucBoardRev;
-extern unsigned char ucBoardRevMaj, ucBoardRevMin;
-
#endif /* CONFIG_PPC_PREP */
#endif /* defined(__KERNEL__) && defined(CONFIG_PPC32) */
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH/RFC] Modify sched_clock() to make CONFIG_PRINTK_TIME more sane.
From: Segher Boessenkool @ 2007-06-19 6:43 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev
In-Reply-To: <20070619063557.GK9768@bakeyournoodle.com>
> When booting a current kernel with CONFIG_PRINTK_TIME enabled you'll
> see messages like:
>
> [ 0.000000] time_init: decrementer frequency = 188.044000 MHz
> [ 0.000000] time_init: processor frequency = 1504.352000 MHz
> [3712914.436297] Console: colour dummy device 80x25
>
> This patch modifies sched_clock() to report the offset since the
> machine booted
> so the same printk's now look like:
>
> [ 0.000000] time_init: decrementer frequency = 188.044000 MHz
> [ 0.000000] time_init: processor frequency = 1504.352000 MHz
> [ 0.000135] Console: colour dummy device 80x25
>
> Effectivly including the uptime in printk()s.
This was long overdue, thank you Tony!
Segher
^ permalink raw reply
* Re: [PATCH] boot: find initrd location from device-tree
From: Segher Boessenkool @ 2007-06-19 6:44 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev, Paul Mackerras, Milton Miller
In-Reply-To: <20070619012557.GB24530@localhost.localdomain>
>>> As I said in the patch changelog, the only headers picked up here are
>>> libgcc.
>>
>> Which the kernel doesn't use. It _should_ be fine
>> nevertheless, <limits.h> is part of the "freestanding"
>> headers -- why do you need to do a "libc" trick though?
>> This doesn't work when not using glibc I guess?
>
> IMO if it needs this define magic to work properly, it's not a good
> idea to include it at all. Especially since avoiding it is easy and
> safe in this case.
100% agreed.
Segher
^ permalink raw reply
* Re: [patch 30/33] PS3: Bootwrapper support.
From: Paul Mackerras @ 2007-06-19 6:44 UTC (permalink / raw)
To: Geoff Levand; +Cc: ppcdev, Milton Miller
In-Reply-To: <46771CE7.8040901@am.sony.com>
Geoff Levand writes:
> This is from the comment the patch adds to the wrapper script. I think
> it gives you what you need:
>
> +ps3)
> + # The ps3's loader supports loading gzipped binary images from flash
> + # rom to addr zero. The loader enters the image at addr 0x100. A
> + # bootwrapper overlay is use to arrange for the kernel to be loaded
> + # to addr zero and to have a suitable bootwrapper entry at 0x100.
> + # To construct the rom image, 0x100 bytes from offset 0x100 in the
> + # kernel is copied to the bootwrapper symbol __system_reset_kernel.
> + # The 0x100 bytes at the bootwrapper symbol __system_reset_overlay is
> + # then copied to offset 0x100. At runtime the bootwrapper program
> + # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.
Yes, that is useful, but Mark is right, your patch description is a
bit terse, and something like that in the patch description would be
useful.
Paul.
^ permalink raw reply
* Re: [patch 23/33] powerpc: Localize mmu_off
From: Paul Mackerras @ 2007-06-19 6:46 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <46730D5B.300@am.sony.com>
Geoff Levand writes:
> This just removes the dependency __mmu_off has on the symbol
> __after_prom_start. I found the current code inconvenient when I
> wanted to put some debugging code between the call to __mmu_off
> and the branch to __after_prom_start.
So we do an extra unnecessary branch... I realize it doesn't really
matter, but on the other hand, if you're hacking around with debug
stuff, you can easily change __after_prom_start to the label where
your debug code starts.
Paul.
^ permalink raw reply
* Re: [patch 18/33] PS3: Frame buffer system-bus rework
From: Paul Mackerras @ 2007-06-19 6:47 UTC (permalink / raw)
To: Geoff Levand; +Cc: Geert Uytterhoeven, linuxppc-dev, linux-fbdev-devel
In-Reply-To: <46730D32.8060803@am.sony.com>
Geoff Levand writes:
> From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
>
> Convert the ps3fb device from a platform device to a PS3 system bus device.
> Fix the remove and shutdown methods to support kexec and to make ps3fb a
> loadable module.
Are you going to submit this to the fb maintainer (Antonio Daplas?) or
do you want me to take it because of dependencies on other patches in
your series?
Paul.
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: Geert Uytterhoeven @ 2007-06-19 7:06 UTC (permalink / raw)
To: David Miller
Cc: axboe, James.Bottomley, linux-scsi, linux-kernel, linuxppc-dev,
paulus, dwmw2, hch, alan
In-Reply-To: <20070618.230357.08341020.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1244 bytes --]
On Mon, 18 Jun 2007, David Miller wrote:
> What I really care about is what will work transparently for existing
> userspace. In particular, distribution installers and existing tools
> like fdisk.
>
> When a slice it being exported, it's not being exported like that so
> that the client can just spam a disk label into it, it's for exporting
> one slice. So we might want (using the scsi naming as an arbitrary
> example case) /dev/sda1 to be created but not /dev/sda
>
> How exactly do you envision this kind of thing working?
How do distribution installers handle USB disks and memory cards? Some tend
to be partitioned, some don't.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 18/33] PS3: Frame buffer system-bus rework
From: Geert Uytterhoeven @ 2007-06-19 7:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-fbdev-devel
In-Reply-To: <18039.31768.282185.497245@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1199 bytes --]
Hi Paul,
On Tue, 19 Jun 2007, Paul Mackerras wrote:
> Geoff Levand writes:
> > From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> >
> > Convert the ps3fb device from a platform device to a PS3 system bus device.
> > Fix the remove and shutdown methods to support kexec and to make ps3fb a
> > loadable module.
>
> Are you going to submit this to the fb maintainer (Antonio Daplas?) or
> do you want me to take it because of dependencies on other patches in
> your series?
I think it's best if you take it, since the changes to ps3fb depend on the
PS3 system bus device core changes.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH 1/2]: Document the global utilities node define and example
From: Zang Roy-r61911 @ 2007-06-19 7:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras
From: Roy Zang <tie-fei.zang@freescale.com>
Document the global utilities node define and example.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
Based on current paul's tree!
Documentation/powerpc/booting-without-of.txt | 28 ++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index d42d981..bdae4fc 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -51,6 +51,7 @@ Table of Contents
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
g) Flash chip nodes
+ k) Global Utilities Block
VII - Specifying interrupt information for devices
1) interrupts property
@@ -1782,6 +1783,33 @@ platforms are moved over to use the flattened-device-tree model.
partition-names = "fs\0firmware";
};
+ k) Global Utilities Block
+
+ The global utilities block controls power management, I/O device
+ enabling, power-on-reset configuration monitoring, general-purpose
+ I/O signal configuration, alternate function selection for multiplexed
+ signals, and clock control.
+
+ Required properties:
+
+ - compatible : Should define the compatible device type for
+ global-utilities.
+ - reg : Offset and length of the register set for the device.
+
+ Recommended properties:
+
+ - fsl,has-rstcr : Indicates that the global utilities register set
+ contains a functioning "reset control register" (i.e. the board
+ is wired to reset upon setting the HRESET_REQ bit in this register).
+
+ Example:
+
+ global-utilities@e0000 { /* global utilities reg */
+ compatible = "fsl,mpc8548-guts";
+ reg = <e0000 1000>;
+ fsl,has-rstcr;
+ };
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
--
1.5.1
^ permalink raw reply related
* [PATCH 2/2]: Fix the node index confusion for SOC
From: Zang Roy-r61911 @ 2007-06-19 7:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras
From: Roy Zang <tie-fei.zang@freescale.com>
Fix the node index confusion for SOC.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
Documentation/powerpc/booting-without-of.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index bdae4fc..419aa57 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -42,15 +42,15 @@ Table of Contents
1) Defining child nodes of an SOC
2) Representing devices without a current OF specification
a) MDIO IO device
- c) PHY nodes
b) Gianfar-compatible ethernet nodes
+ c) PHY nodes
d) Interrupt controllers
e) I2C
f) Freescale SOC USB controllers
g) Freescale SOC SEC Security Engines
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
- g) Flash chip nodes
+ j) Flash chip nodes
k) Global Utilities Block
VII - Specifying interrupt information for devices
--
1.5.1
^ permalink raw reply related
* Re: [patch 4/6] ps3: Disk Storage Driver
From: Christoph Hellwig @ 2007-06-19 8:15 UTC (permalink / raw)
To: David Miller
Cc: James.Bottomley, axboe, linux-scsi, linux-kernel, linuxppc-dev,
paulus, Geert.Uytterhoeven, dwmw2, hch, alan
In-Reply-To: <20070618.230731.11645150.davem@davemloft.net>
On Mon, Jun 18, 2007 at 11:07:31PM -0700, David Miller wrote:
> The main disk I/O block read and write is done using descriptors
> sent to the disk server. SCSI pass-through is provided (optionally)
> so that disk analysis tools can do things like MODE_SENSE on the
> disk.
SG_IO can easily be implemented for block devices. See cciss in
current mainline for an example.
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Gerhard Pircher @ 2007-06-19 8:40 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070619054232.GB32039@localhost.localdomain>
-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 15:42:32 +1000
Von: David Gibson <david@gibson.dropbear.id.au>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, "list <linuxppc-dev"@ozlabs.org
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc
> > 3. The dts files define the device_type of a serial port as
> > "serial", whereas the OF spec says "pnpPNP,501". What's the
> > difference between the two?
>
> Err... device_type == "pnpPNP,501", or compatible == "pnpPNP,501"?
Sorry, I meant compatible = "ns16550" and compatible = "pnpPNP,501".
> This node has no children, so #address-cells and #size-cells values
> are meaningless.
Ah, I thought these properties are always necessary, if a ranges or reg
property is defined.
> > interrupt-controller {
> > device_type = "interrupt-controller";
> > compatible = "chrp,iic";
>
> Is there a device binding defined somewhere for "chrp,iic"?
Dunno. :-) It's based on these document here:
http://playground.sun.com/1275/bindings/devices/html/isa-pic-1_1d.html
http://playground.sun.com/1275/bindings/pci/pci2_1.pdf
> This should cause a dtc error. Either you want &/interrupt-controller
> or give the interrupt-controller node a label and refer to that. It's
> either '&/some/full/path' or '&label'.
That makes sense.
> > timer@40 {
> > device_type = "timer";
>
> For flat device trees we're generally avoiding setting the device_type
> property unless there is a clearly defined "class binding" which
> applies. There are a number of cases here where I'm not sure if
> that's true.
What about platforms that provide a real OF device tree? Do they define
device nodes for timers?
> > clock-frequency = <0>; // Not necessary?
>
> Probably necessary, but may need to be filled in from the bootwrapper.
This should be a constant anyway, so I can define it here.
> > fdc@3f0 {
> > device_type = "fdc";
> > compatible = "pnpPNP,700";
> > reg = <3f0 8>;
> > interrupts = <6 3>;
> > interrupt-parent = <&interrupt-controller>;
> > /* dma = < >;*/
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > disk {
> > device_type = "block";
> > reg = <0>;
> > };
> >
> Don't think you need this subnode.
It's mentioned here (if I interpreted it correctly):
http://playground.sun.com/1275/bindings/devices/html/fdc.html
Not sure, if the Linux kernel needs it.
Thanks!
regards,
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: [PATCH 1/2]: Document the global utilities node define and example
From: Segher Boessenkool @ 2007-06-19 8:49 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1182237558.3269.14.camel@localhost.localdomain>
> Document the global utilities node define and example.
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Thanks for documenting this stuff. One nit though...
> + global-utilities@e0000 { /* global utilities reg */
s/reg/block/ . It's not a single 32768 bit register I'm
sure (how would you access it?!) :-)
Segher
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Gerhard Pircher @ 2007-06-19 9:08 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <136ef2695edbe7c8a535b5b4c7a669bf@kernel.crashing.org>
-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 08:08:42 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
CC: ppcdev list <linuxppc-dev@ozlabs.org>
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc
> Just name the cpu nodes "cpu@0" etc. The "generic names"
> recommended practice wants this, and the node names here
> aren't actually used by anything anyway, except they look
> nice to the user. The PowerPC ISA binding predates the
> generic names r.p. btw.
Good! That simplifies the (yet to be written) amigaone-cuboot.c
bootwrapper code a lot.
> > 3. The dts files define the device_type of a serial port as "serial",
> > whereas the OF spec says "pnpPNP,501". What's the difference between
> > the two?
>
> "device_type" is "serial", "compatible" is "pnpPNP,whatever".
Sorry, I was thinking about compatible = "ns16550" and
compatible = "pnp..", but wrote device_type = "serial".
What's the difference between "ns16550" and "pnpPNP,501"?
> Where in the OF specs did you find this pnpPNP thing btw?
See here:
http://playground.sun.com/1275/bindings/devices/html/serial.html
or
Quote from the document:
> "compatible" S
> Standard property name, specifies device names with which this
> device is compatible.
>
> The meaning of this property is as defined in Open Firmware,
> as modified by the Generic Names Recommended Practice [7]. As
> described in those documents, the entries are a list of device
> names with which this device is compatible, starting with the
> name of the device itself and progressing through successively
> less precise and possibly less functional compatible devices.
>
> For this device, the compatible property shall include "pnpPNP,501."
- End -
> "name" = "device_type" = "interrupt-controller".
> "compatible" is one of those pnpPNP things.
Quote from the "CHRP(TM) ISA Interrupt Controller Device
Binding" document:
> "compatible" S
> Standard property name, specifies device names with which
> this device is compatible.
> ....
> The compatible property shall include "chrp,iic."
- End -
I couldn't find any reference about a "pnp..." value for an i8259
interrupt controller. Is there already a generic function within the
kernel that can setup the interrupt controller based solely on the
information in the device tree?
> Please send the thing inline, not as an attachment.
Okay, will do so next time.
Thanks!
regards,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Segher Boessenkool @ 2007-06-19 9:14 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070619084015.202120@gmx.net>
>>> 3. The dts files define the device_type of a serial port as
>>> "serial", whereas the OF spec says "pnpPNP,501". What's the
>>> difference between the two?
>>
>> Err... device_type == "pnpPNP,501", or compatible == "pnpPNP,501"?
> Sorry, I meant compatible = "ns16550" and compatible = "pnpPNP,501".
"pnpPNP,501" says that the device is a 16550A-compatible
UART compatible with how that is used in a PC (using the
same base clock, and some other minor things).
"ns16550" simply says the device is compatible with
the NS16550. Also note the lack of "A".
>> This node has no children, so #address-cells and #size-cells values
>> are meaningless.
> Ah, I thought these properties are always necessary, if a ranges or reg
> property is defined.
They are necessary if one of the children has a "reg" or
"ranges" or similar, or if this node has a "ranges"
property. "#xxx-cells" defines the number of cells for
the bus that this node is the controller for. So, for
"reg", the relevant #xxx-cells entry is that in your parent;
for "ranges" you need both the "#address-cells" entry in
your parent and your own #xxx-cells values (since "ranges"
uses parent bus address, child bus address, child bus size).
>>> interrupt-controller {
>>> device_type = "interrupt-controller";
>>> compatible = "chrp,iic";
>>
>> Is there a device binding defined somewhere for "chrp,iic"?
> Dunno. :-) It's based on these document here:
> http://playground.sun.com/1275/bindings/devices/html/isa-pic-1_1d.html
> http://playground.sun.com/1275/bindings/pci/pci2_1.pdf
How does PCI come into the picture here?
>>> timer@40 {
>>> device_type = "timer";
>>
>> For flat device trees we're generally avoiding setting the device_type
>> property unless there is a clearly defined "class binding" which
>> applies. There are a number of cases here where I'm not sure if
>> that's true.
> What about platforms that provide a real OF device tree? Do they define
> device nodes for timers?
Sure. There typically is a device node for every
(addressable) device on the system. There is no
defined binding for timer devices though, so there
shouldn't be a "device_type" in a timer node.
>>> clock-frequency = <0>; // Not necessary?
Since this is an AT timer, you should use "compatible"
= "pnpPNP,100", and the clock frequency is implicit.
>>> fdc@3f0 {
>>> disk {
>>> device_type = "block";
>>> reg = <0>;
>>> };
>>>
>> Don't think you need this subnode.
> It's mentioned here (if I interpreted it correctly):
> http://playground.sun.com/1275/bindings/devices/html/fdc.html
"disk" subnodes describe the floppy disk _drives_ actually.
You should have a disk@0 and/or a disk@1, if you have any
floppy disk drives at all that is.
> Not sure, if the Linux kernel needs it.
The linux floppy driver will do its own probing, so no
it won't care. Can't hurt to include it though.
In real OF these nodes are very necessary of course,
since without device node you cannot use it to read
files from.
Segher
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Segher Boessenkool @ 2007-06-19 9:28 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070619090816.55840@gmx.net>
>> Where in the OF specs did you find this pnpPNP thing btw?
> See here:
> http://playground.sun.com/1275/bindings/devices/html/serial.html
Ah, the CHRP stuff I so happily ignore.
The generic pnpPNP thing is described in the ISA binding,
4.1.1 "name". You should put this into "compatible"
though, since generic names are preferred.
>> "compatible" is one of those pnpPNP things.
>
> Quote from the "CHRP(TM) ISA Interrupt Controller Device
> Binding" document:
But you're not CHRP. This is an ISA device however,
so you should follow the ISA binding.
> I couldn't find any reference about a "pnp..." value for an i8259
> interrupt controller.
pnpPNP,0 for AT-style, pnpPNP,1 for EISA-style.
It is quite hard to find a list of the standard PNP
device code. Here's a link, grab it before the file
disappears forever:
<http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a
-923143f3456c/devids.txt>
> Is there already a generic function within the
> kernel that can setup the interrupt controller based solely on the
> information in the device tree?
Probably not. There are bits and pieces though, your
job is to glue it all together. You can handle this
in your platform code, if people want to make it more
generic they can always refactor the code ;-)
Segher
^ permalink raw reply
* Re: booting zImage.elf
From: David H. Lynch Jr. @ 2007-06-19 9:37 UTC (permalink / raw)
To: Shelley, Mike; +Cc: linuxppc-embedded
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE4871084A0ED0@VCAEXCH01.hq.corp.viasat.com>
An elf file is not just a collection of bits exactly as they would
be found in memory.
The code in it may get loaded into several distinct regions, it may
include information to allocate additional regions,
the code may be relocatable or have relocation information.
It is unlikely (maybe impossible) that you can create an elf file
that you can just jump into.
There are other file formats that you can build the kernel as that
would more closely correspond to what you are after.
Because I normally build zImage.elf files and my loader handles
them well I am not experienced with creating other formats,
but I think the u-boot documentation should give you some pointers.
You do not convert the zImage.elf, you build the kernel with the
image format that you want.
zImage.elf is actually a very simple elf file, that performs some
rudimentary initialization, and then decompresses what is really the
kernel image into memory
and executes it. The compressed image inside the zImage.elf is
closer to what you are looking for.
Shelley, Mike wrote:
> I've been trying to read up on how elf works and how to boot the linux kernel image with a custom boot loader. I can't seem to find anything about booting an elf image. I'm using a PCI Express XpressFX Board (which has a Virtex4), by PLDA, with DDR2 memory. I've got the kernel image booting using a BDI to load it. Now I need to get it to load without the BDI.
>
> The quick question is, Is it possible to load zImage.elf straight into memory, then jump to the address it was loaded to? If not, how do I convert the elf image into just a bootable image that I can jump to?
>
> I looked at the uboot code to load elf files, and it appears to copy the sections around. Is this necessary?
>
> Pointers on where else to look or how to do this would be greatly appreciated.
>
> Michael
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH 1/2]: Document the global utilities node define and example
From: Zang Roy-r61911 @ 2007-06-19 9:41 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <b653522c06e6053167988bb8bcf3a868@kernel.crashing.org>
On Tue, 2007-06-19 at 16:49, Segher Boessenkool wrote:
> > Document the global utilities node define and example.
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>
> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
>
> Thanks for documenting this stuff. One nit though...
>
> > + global-utilities@e0000 { /* global utilities reg */
>
> s/reg/block/ . It's not a single 32768 bit register I'm
> sure (how would you access it?!) :-)
I access it by a 32768 bit wide bus -:)!
Roy
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Gerhard Pircher @ 2007-06-19 9:52 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, david
In-Reply-To: <73aafd0955b8ea695af9221b48aaa3f1@kernel.crashing.org>
-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 11:14:44 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc
> "pnpPNP,501" says that the device is a 16550A-compatible
> UART compatible with how that is used in a PC (using the
> same base clock, and some other minor things).
>
> "ns16550" simply says the device is compatible with
> the NS16550. Also note the lack of "A".
I guess I can define both of them or do they conflict (IIRC
the two hardware revision should be compatible)?
> >> Is there a device binding defined somewhere for "chrp,iic"?
> > Dunno. :-) It's based on these document here:
> > http://playground.sun.com/1275/bindings/devices/html/isa-pic-1_1d.html
> > http://playground.sun.com/1275/bindings/pci/pci2_1.pdf
>
> How does PCI come into the picture here?
I just added it, because it defines how the interrupts property
should be specfied.
> Sure. There typically is a device node for every
> (addressable) device on the system. There is no
> defined binding for timer devices though, so there
> shouldn't be a "device_type" in a timer node.
Okay, I'll remove the device_type property.
> >>> clock-frequency = <0>; // Not necessary?
>
> Since this is an AT timer, you should use "compatible"
> = "pnpPNP,100", and the clock frequency is implicit.
Where are all this "pnpPNP,xxx" identifiers specified (except
for serial parallel, fdc, keyboard, mouse)?
> "disk" subnodes describe the floppy disk _drives_ actually.
> You should have a disk@0 and/or a disk@1, if you have any
> floppy disk drives at all that is.
Ah yes, I may have forgotten the "@0" by mistake.
> The linux floppy driver will do its own probing, so no
> it won't care. Can't hurt to include it though.
That was my intention.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* [PATCH] lite5200b: flash definition in dts
From: Domen Puncer @ 2007-06-19 9:54 UTC (permalink / raw)
To: linuxppc-embedded
Add flash definition for flash on lite5200b, and while at it
fix "ranges" for soc node.
Kernel now writes:
[ 11.159134] fe000000.flash: Found 2 x8 devices at 0x0 in 16-bit bank
[ 11.165696] Amd/Fujitsu Extended Query Table at 0x0040
[ 11.171109] fe000000.flash: CFI does not contain boot bank location. Assuming top.
[ 11.178911] number of CFI chips: 1
[ 11.182427] cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
[ 11.190402] RedBoot partition parsing not available
[ 11.195449] physmap-flash fe000000.flash: Using OF partition information
[ 11.202359] Creating 2 MTD partitions on "fe000000.flash":
[ 11.208023] 0x00000000-0x01f00000 : "data"
[ 11.213712] 0x01f00000-0x02000000 : "u-boot"
I have not managed to write anything to flash from Linux, ideas?
JEDEC probe does not succeed.
CFI does (cfi_ident struct is filled and "looks" OK),
but mfr and id are 0xffff.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
arch/powerpc/boot/dts/lite5200b.dts | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
===================================================================
--- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
+++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
@@ -52,11 +52,23 @@
revision = ""; // from bootloader
#interrupt-cells = <3>;
device_type = "soc";
- ranges = <0 f0000000 f0010000>;
+ ranges = <00000000 f0000000 00010000
+ fe000000 fe000000 02000000>;
reg = <f0000000 00010000>;
bus-frequency = <0>; // from bootloader
system-frequency = <0>; // from bootloader
+ flash@fe000000 {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ probe-type = "CFI";
+ reg = <fe000000 02000000>;
+ bank-width = <2>;
+ partitions = <00000000 01f00000
+ 01f00000 00100000>;
+ partition-names = "data", "u-boot";
+ };
+
cdm@200 {
compatible = "mpc5200b-cdm\0mpc5200-cdm";
reg = <200 38>;
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Segher Boessenkool @ 2007-06-19 10:08 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, david
In-Reply-To: <20070619095251.202080@gmx.net>
>> "pnpPNP,501" says that the device is a 16550A-compatible
>> UART compatible with how that is used in a PC (using the
>> same base clock, and some other minor things).
>>
>> "ns16550" simply says the device is compatible with
>> the NS16550. Also note the lack of "A".
> I guess I can define both of them or do they conflict (IIRC
> the two hardware revision should be compatible)?
Use one or the other, not both. Perhaps you'll need
to add the pnpPNP,500 and pnpPNP,501 entries to the
generic OF serial code, should be trivial to do.
The 16550A supports something the 16550 doesn't (don't
ask me what, I forgot :-) ), so don't say it is an A
when it isn't; the other way around is fine though.
And it doesn't matter much for Linux anyway currently,
the "generic" kernel driver will do its own wacky probing.
>>> http://playground.sun.com/1275/bindings/pci/pci2_1.pdf
>>
>> How does PCI come into the picture here?
> I just added it, because it defines how the interrupts property
> should be specfied.
"interrupts" is defined by the base OF spec. The specific
format for any interrupt domain is defined by the binding
for that domain, notably by the bindings for interrupt
controllers.
> Where are all this "pnpPNP,xxx" identifiers specified (except
> for serial parallel, fdc, keyboard, mouse)?
They are defined by the vendor of the devices; for
vendor "PNP", i.e. legacy non-PNP PC devices, that
is MicroSoft.
Segher
^ permalink raw reply
* Regarding SCC in DTS
From: b.vigneshkumar @ 2007-06-19 10:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
Hi,
This SCC Config in DTS has some thing like the following. Can You
Explain the two lines. I would be grateful to you if you could help me
understanding. What is that 1e and 3 doing? What does the
interrupt-parent doing?
scc@a00 {
.......
interrupts = <1e 3>;
interrupt-parent = <&Cpm_pic>;
}
Regards,
Vignesh Kumar
[-- Attachment #2: b.vigneshkumar.vcf --]
[-- Type: text/x-vcard, Size: 178 bytes --]
begin:vcard
fn:Vignesh Kumar Bagavathsingh
n:Bagavathsingh;Vignesh Kumar
email;internet:b.vigneshkumar@gdatech.com
tel;work:6513
tel;home:044-23773210
version:2.1
end:vcard
^ permalink raw reply
* random code execution - kernel oops
From: Johannes Berg @ 2007-06-18 13:04 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 4969 bytes --]
unsigned long hx = 0x4bfcc50c;
int main()
{
asm("bl hx");
}
yields:
[101274.818295] Unable to handle kernel paging request for data at address 0x0ffdc000
[101274.818313] Faulting instruction address: 0xc00122a8
[101274.818330] Oops: Kernel access of bad area, sig: 11 [#11]
[101274.818335] PREEMPT PowerMac
[101274.818341] Modules linked in: nls_iso8859_15 isofs zlib_inflate udf af_packet binfmt_misc radeon drm hci_usb rfcomm l2cap bluetooth snd_powermac configfs nls_utf8 hfsplus nls_base fuse dm_snapshot dm_mirror sha256 joydev snd_aoa_codec_tas snd_aoa_fabric_layout appletouch snd_aoa usbhid firewire_ohci firewire_core crc_itu_t bcm43xx ieee80211softmac ieee80211 ieee80211_crypt arc4 snd_aoa_i2sbus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc rc80211_simple snd soundcore ohci1394 ieee1394 snd_aoa_soundbus bcm43xx_mac80211 ssb ehci_hcd pcmcia firmware_class mac80211 ohci_hcd cfg80211 yenta_socket rsrc_nonstatic usbcore uninorth_agp pcmcia_core agpgart evdev unix
[101274.818448] NIP: c00122a8 LR: c0015950 CTR: 00000080
[101274.818456] REGS: cb157cd0 TRAP: 0300 Not tainted (2.6.22-rc4-g7d59453a-dirty)
[101274.818463] MSR: 00009032 <EE,ME,IR,DR> CR: 33003353 XER: 80000000
[101274.818478] DAR: 0ffdc000, DSISR: 40000000
[101274.818485] TASK = cfc56670[19956] '0x4bfcc50c' THREAD: cb156000
[101274.818490] GPR00: cfc0dc40 cb157d80 cfc56670 0ffdc000 00000080 22723101 0ffdc000 40000000
[101274.818508] GPR08: c084e000 cfc0dc40 00000000 c084e000 0000015b 100189a0 c0610000 0ffdc000
[101274.818525] GPR16: c05f8a10 100d0000 fe3fffff 00000000 ca437200 00000000 d2b170fc c0610000
[101274.818542] GPR24: cfc0dc40 00000f70 0ffdceac ec849a58 ec849a58 0ffdceac 22723101 c0c9c460
[101274.818560] NIP [c00122a8] __flush_dcache_icache+0x14/0x40
[101274.818580] LR [c0015950] update_mmu_cache+0xec/0xf0
[101274.818591] Call Trace:
[101274.818596] [cb157d80] [00000f70] 0xf70 (unreliable)
[101274.818610] [cb157da0] [c0079cec] __handle_mm_fault+0x2d8/0xbe4
[101274.818623] [cb157e10] [c0301aa8] do_page_fault+0x41c/0x554
[101274.818640] [cb157f40] [c00119f4] handle_page_fault+0xc/0x80
[101274.818650] --- Exception: 401 at 0xffdceac
[101274.818660] LR = 0x1000043c
[101274.818664] Instruction dump:
[101274.818670] 4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 60000000
[101274.818687] 54630026 38800080 7c8903a6 7c661b78 <7c00186c> 38630020 4200fff8 7c0004ac
[101274.818707] note: 0x4bfcc50c[19956] exited with preempt_count 2
[101274.818716] BUG: sleeping function called from invalid context at kernel/rwsem.c:20
[101274.818723] in_atomic():1, irqs_disabled():0
[101274.818727] Call Trace:
[101274.818732] [cb157bc0] [c0008e10] show_stack+0x3c/0x194 (unreliable)
[101274.818748] [cb157bf0] [c0027648] __might_sleep+0xd0/0xec
[101274.818764] [cb157c00] [c00494d4] down_read+0x24/0x5c
[101274.818778] [cb157c20] [c005cda4] acct_collect+0x44/0x1a4
[101274.818793] [cb157c40] [c0030470] do_exit+0x10c/0x8c4
[101274.818805] [cb157c80] [c000ff34] die+0x210/0x218
[101274.818815] [cb157cb0] [c0015600] bad_page_fault+0x90/0xd8
[101274.818825] [cb157cc0] [c0011a64] handle_page_fault+0x7c/0x80
[101274.818835] --- Exception: 300 at __flush_dcache_icache+0x14/0x40
[101274.818846] LR = update_mmu_cache+0xec/0xf0
[101274.818852] [cb157d80] [00000f70] 0xf70 (unreliable)
[101274.818901] [cb157da0] [c0079cec] __handle_mm_fault+0x2d8/0xbe4
[101274.818911] [cb157e10] [c0301aa8] do_page_fault+0x41c/0x554
[101274.818923] [cb157f40] [c00119f4] handle_page_fault+0xc/0x80
[101274.818933] --- Exception: 401 at 0xffdceac
[101274.818942] LR = 0x1000043c
[101274.818961] BUG: scheduling while atomic: 0x4bfcc50c/0x10000002/19956
[101274.818967] Call Trace:
[101274.818971] [cb157ac0] [c0008e10] show_stack+0x3c/0x194 (unreliable)
[101274.818984] [cb157af0] [c02fe44c] schedule+0x584/0x6b4
[101274.818994] [cb157b40] [c00276f4] __cond_resched+0x34/0x60
[101274.819006] [cb157b50] [c02fe8f4] cond_resched+0x50/0x58
[101274.819016] [cb157b60] [c0077964] unmap_vmas+0x698/0x6b4
[101274.819026] [cb157be0] [c007c558] exit_mmap+0x74/0x120
[101274.819036] [cb157c10] [c002a1f0] mmput+0x68/0xf8
[101274.819048] [cb157c20] [c002e7fc] exit_mm+0xac/0x110
[101274.819058] [cb157c40] [c0030484] do_exit+0x120/0x8c4
[101274.819067] [cb157c80] [c000ff34] die+0x210/0x218
[101274.819077] [cb157cb0] [c0015600] bad_page_fault+0x90/0xd8
[101274.819087] [cb157cc0] [c0011a64] handle_page_fault+0x7c/0x80
[101274.819097] --- Exception: 300 at __flush_dcache_icache+0x14/0x40
[101274.819109] LR = update_mmu_cache+0xec/0xf0
[101274.819115] [cb157d80] [00000f70] 0xf70 (unreliable)
[101274.819125] [cb157da0] [c0079cec] __handle_mm_fault+0x2d8/0xbe4
[101274.819135] [cb157e10] [c0301aa8] do_page_fault+0x41c/0x554
[101274.819147] [cb157f40] [c00119f4] handle_page_fault+0xc/0x80
[101274.819157] --- Exception: 401 at 0xffdceac
[101274.819166] LR = 0x1000043c
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ 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