* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: David Gibson @ 2007-12-23 23:03 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <476D61DB.2090201@scram.de>
On Sat, Dec 22, 2007 at 08:13:31PM +0100, Jochen Friedrich wrote:
> This patch adds device tree source, default config and setup code for
> DBox2 devices.
[snip]
> diff --git a/arch/powerpc/boot/dts/dbox2.dts b/arch/powerpc/boot/dts/dbox2.dts
> new file mode 100644
> index 0000000..8d91510
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/dbox2.dts
> @@ -0,0 +1,263 @@
> +/*
> + * DBOX2 Device Tree Source
> + *
> + * Copyright 2007 Jochen Friedrich <jochen@scram.de>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +/ {
> + model = "Dbox2";
> + compatible = "betaresearch,dbox2";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,823@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <d#16>;
> + i-cache-line-size = <d#16>;
> + d-cache-size = <d#1024>;
> + i-cache-size = <d#2048>;
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + interrupts = <f 2>; // decrementer interrupt
> + interrupt-parent = <&PIC>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 2000000>;
> + };
> +
> + localbus@8000000 {
> + compatible = "betaresearch,dbox2-localbus";
Is this bus interface really board specific? I would have thought the
localbus bridge would have been part of the SoC in which case the
compatible string should mention the 823 rather than the dbox.
> + #address-cells = <1>;
It's also usual for these localbus things, to have #address-cells of
2, with the chipselect explicitly present as the first cell.
> + #size-cells = <1>;
> + reg = <8000000 18000000>;
> +
> + ranges = <0 8000000 18000000>;
> +
> + enx@0 {
> + compatible = "c-cube,enx";
What are these mysterious enx, gtx, etc. devices? Some comments might
be nice.
[snip]
> + flash@8000000 {
> + // Flash also has info about model needed by setup
> + compatible = "cfi-flash",
> + "betaresearch,dbox2-config";
compatible strings should be listed with most specific first, most
general last. That would put "cfi-flash" after the dbox2 specific
string, I believe.
[snip]
> + soc@ff000000 {
> + compatible = "fsl,mpc823",
> + "fsl,pq1-soc";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0 ff000000 00004000>;
> + reg = <ff000000 00004000>;
> + bus-frequency = <0>;
> +
> + PIC: pic@0 {
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <0 24>;
> + compatible = "fsl,mpc823-pic",
> + "fsl,pq1-pic";
> + };
> +
> + wdt@0 {
> + device_type = "watchdog";
Drop this device_type.
> + compatible = "fsl,mpc823-wdt",
> + "fsl,pq1-wdt";
> + reg = <0 10>;
> + };
> +
> + cpm@9c0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + reg = <9c0 40>;
> + command-proc = <9c0>;
> + interrupts = <0 2>; // cpm error interrupt
> + interrupt-parent = <&CPM_PIC>;
> + compatible = "fsl,mpc823-cpm",
> + "fsl,cpm1";
> +
> + muram@2000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 2000 2000>;
> +
> + data@0 {
> + compatible = "fsl,cpm-muram-data";
> + reg = <0 1c00>;
> + };
> + };
> +
> + // Port D is LCD exclusive. Don't export as GPIO
> + CPM1_PIO: pio@970 {
> + compatible = "fsl,cpm1-pario";
> + reg = <970 180>;
> + num-ports = <3>;
> + #gpio-cells = <2>;
> + };
> +
> + lcd@970 {
> + reg = <970 10>;
> + compatible = "samsung,ks0713";
Is this representing an LCD controller, or the display itself. Either
way I'm surprised there's something here in the SoC that has a
compatible string that's not "fsl,something"
--
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: Yet more patches added to for-2.6.25/master branches
From: Paul Mackerras @ 2007-12-23 23:32 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1198320960.11901.9.camel@pmac.infradead.org>
David Woodhouse writes:
> http://patchwork.ozlabs.org/linuxppc/patch?id=15192 ?
Not my bailiwick. Send it to the RTC subsystem maintainer or Andrew
Morton. You can put Acked-by me on it if you like.
Paul.
^ permalink raw reply
* Re: [RESEND DTC PATCH 2/2] Add support for binary includes.
From: David Gibson @ 2007-12-24 0:16 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl, u-boot-users
In-Reply-To: <20071222135716.GA16187@ld0162-tx32.am.freescale.net>
On Sat, Dec 22, 2007 at 07:57:17AM -0600, Scott Wood wrote:
> On Sat, Dec 22, 2007 at 01:51:30PM +1100, David Gibson wrote:
> > On Fri, Dec 21, 2007 at 11:09:21AM -0600, Scott Wood wrote:
> > > OK. I was being lazy. :-P
> >
> > In general I'd approve, but having to invoke dtc in the right place
> > for the dts file is a bit too big a usability problem, I think.
>
> Yeah, I agree. It looks like the existing /include/ has the same
> problem, BTW.
Uh, yes, I guess it would. I suppose we'd better fix that too. We'll
see how bored I get at my parents' place over Christmas.
> > > Yeah, I wanted something that would cause dtc to return an error code,
> > > and it doesn't seem that calling yyerror(f) will do that at present. I
> > > guess I should fix that rather than overload YYERROR.
> >
> > No. As per the yacc interface, yyerror() prints only, it doesn't
> > terminate.
>
> I don't mean terminate early, just set a flag indicating there were
> errors, so it returns an error code once parsing is done.
Ok. We don't have a really good mechanism for that at present - for
any of the input forms. I was thinking about trying to hook that into
the checking framework - have a special sort of check that doesn't do
anything when invoked as a check, but can be "pre-failed" by the input
parsing code.
> > > > I'm also not sure that stat()ing the file is a good way to get the
> > > > size. This requires that the included file be a regular file with a
> > > > sane st_size value, and I can imagine cases where it might be useful
> > > > to incbin from a /dev node or other special file. Obviosuly
> > > > implementing that will require work to data_copy_file().
> > >
> > > Hmm... do you have a use case in mind?
> >
> > Nothing really specific. I'm thinking of a dts that maybe pulls in
> > some blobs from a pre-existing firmware, by sucking in files from
> > /proc/device-tree.
>
> 'ls -l /proc/device-tree' seems to indicate that stat would work fine
> there (and fstree.c uses it).
Uh, yeah. That's just me being an old-timer and remembering the days
when stat() didn't operate on /proc properly.
> > Or maybe something to produce a dts for a guest under a hypervisor that
> > takes an image of a real NVRAM or other device to embed in the tree as
> > a virtual NVRAM for the guest.
>
> OK.
>
> > > > Actually, I think the way to go here would be to have two variants of
> > > > the incbin directive: one which takes just a filename and includes
> > > > the whole file contents, another which takes a filename and a number
> > > > and includes just the first N bytes of the file.
> > >
> > > Maybe. /incbinrange/ "path/name" start len?
> >
> > I'd prefer to avoid two different keywords if possible. I'll see if I
> > can think of a reasonable syntax.
>
> /incbin/("path")
> /incbin/("path", start, len)
Hrm. Not all that fond of those, but we'll see. I guess
C-function-like syntax does make a certain amount of sense in the
context of the expression syntax we intend to introduce.
--
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 1/21] [POWERPC] Reworking machine check handling and Fix 440/440A
From: Josh Boyer @ 2007-12-24 1:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071221043925.42B40DDE30@ozlabs.org>
On Fri, 21 Dec 2007 15:39:21 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Index: linux-merge/arch/powerpc/kernel/traps.c
> ===================================================================
> --- linux-merge.orig/arch/powerpc/kernel/traps.c 2007-12-20 11:34:43.000000000 +1100
> +++ linux-merge/arch/powerpc/kernel/traps.c 2007-12-20 11:35:40.000000000 +1100
[snip]
> -#elif defined (CONFIG_E500)
> + return 0;
> +}
> +#elif defined(CONFIG_E500)
> +int machine_check_e500(struct pt_regs *regs)
This...
> +{
> + unsigned long reason = get_mc_reason(regs);
> +
> printk("Machine check in kernel mode.\n");
> printk("Caused by (from MCSR=%lx): ", reason);
>
> @@ -403,7 +416,14 @@ static int generic_machine_check_excepti
> printk("Bus - Instruction Parity Error\n");
> if (reason & MCSR_BUS_RPERR)
> printk("Bus - Read Parity Error\n");
> -#elif defined (CONFIG_E200)
> +
> + return 0;
> +}
> +#elif defined(CONFIG_E200)
> +int machine_check_e200(struct pt_regs *regs)
... and this cause build failures for most of the mpc8xxx defconfigs.
The reason is that e200 and e500 are both lumped under CONFIG_FSL_BOOKE
in cputable.c, but you have them segregated more here. I've added a
fix that just does CONFIG_FSL_BOOKE here to match cputable.c.
josh
^ permalink raw reply
* Re: Build breakage on powerpc with 2.6.24-rc6-mm1
From: Stephen Rothwell @ 2007-12-24 2:43 UTC (permalink / raw)
To: balbir; +Cc: linuxppc-dev, akpm, gregkh, linux-kernel
In-Reply-To: <20071223224158.GA7975@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
Hi Balbir,
Thanks for the report.
On Mon, 24 Dec 2007 04:11:58 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>
> I see the following error with the iseries_veth driver in 2.6.24-rc6-mm1
>
> drivers/net/iseries_veth.c: In function ‘veth_init_connection’:
> drivers/net/iseries_veth.c:818: warning: unused variable ‘rc’
> drivers/net/iseries_veth.c: In function ‘veth_probe_one’:
> drivers/net/iseries_veth.c:1086: error: ‘veth_port_ktypeq’ undeclared
> (first use in this function)
> drivers/net/iseries_veth.c:1086: error: (Each undeclared identifier is
> reported only once
> drivers/net/iseries_veth.c:1086: error: for each function it appears
> in.)
> make[2]: *** [drivers/net/iseries_veth.o] Error 1
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
Yeah, that would be
gregkh-driver-kobject-convert-drivers-net-iseries_vethc-to-use-kobject_init-add_ng.
Hi Greg, do you even build with your patches applied?
> Here's a patch, compile tested to fix the compilation problem
Hopefully Greg will fix his original patch before it reaches Linus.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: drivers/net/iseries_veth.c dubious sysfs usage
From: Stephen Rothwell @ 2007-12-24 2:52 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, David Gibson, linuxppc-dev, Kyle A. Lucke, paulus
In-Reply-To: <20071213070829.GA13764@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
Hi Greg,
On Wed, 12 Dec 2007 23:08:29 -0800 Greg KH <greg@kroah.com> wrote:
>
> Hm, ok, it's odd as you are the only driver in the whole tree doing
> something like this, but it seems semi-resonable, so I can't complain :)
>
> I'll fix the core up to allow you to do this, thanks for the
> explanation.
So if this "seems semi-reasonable", why was the result
gregkh-driver-driver-add-driver_add_kobj-for-looney-iseries_veth-driver
containing "Hopefully no one uses this function in the future and the
iseries_veth driver authors come to their senses so I can remove this
hack..." as part of its comment. If you expect respect, you need to
treat others the same way ...
If what the driver writers are doing is "looney" (in your opinion), then
please describe a better way of doing what they are trying to do.
Sometimes, if people have to abuse the infrastructure, it is possible that
the infrastructure is lacking?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Loop at starting pid 164, tty '': '/sbin/getty'
From: Olof Johansson @ 2007-12-24 4:09 UTC (permalink / raw)
To: ramkumarj Ramkumar; +Cc: linuxppc-embedded
In-Reply-To: <4f8c3030712220051if731af9g350af9d45a75c244@mail.gmail.com>
Hi,
On Sat, Dec 22, 2007 at 04:51:16PM +0800, ramkumarj Ramkumar wrote:
> I m trying to run Linux 2.6 ( From Grant) on ML-403. I used the
> busybox-1.7.2. During booting, I found the following logs and it keeps
> trying to respawn the getty.It keeps looping and I never see the login
> prompt. Am I missing something.
>
> process '/sbin/getty 38400 tts/0' (pid 163) exited. Scheduling it for
> restart.
Do you have a /dev/ttys/0? First serial port is normally /dev/ttyS0.
-Olof
^ permalink raw reply
* SCSI errors on powerpc with 2.6.24-rc6-mm1
From: Balbir Singh @ 2007-12-24 4:48 UTC (permalink / raw)
To: linuxppc-dev, akpm; +Cc: linux-kernel, linux-scsi
Hi,
I've just seen this on my dmesg, this is new, never seen this before on
this box and it happens only with this version of the kernel.
In this configuration, the page size is set to 64K and I've enabled fake
NUMA nodes on PowerPC.
tce_buildmulti_pSeriesLP: plpar_tce_put failed. rc=-4
index = 0x4000002
npages = 0x0
tce[0] val = 0x15ad0001
Call Trace:
[c00000000ffe74f0] [c0000000000491a4]
.tce_buildmulti_pSeriesLP+0x26c/0x2ac (unreliable)
[c00000000ffe75c0] [c0000000000295e4] .iommu_map_sg+0x1d4/0x418
[c00000000ffe76d0] [c000000000028664] .dma_iommu_map_sg+0x3c/0x50
[c00000000ffe7750] [c0000000003b6c30] .scsi_dma_map+0x70/0x94
[c00000000ffe77d0] [c0000000003dedbc] .ipr_queuecommand+0x300/0x500
[c00000000ffe7880] [c0000000003ae964] .scsi_dispatch_cmd+0x21c/0x2b8
[c00000000ffe7920] [c0000000003b67a0] .scsi_request_fn+0x310/0x460
[c00000000ffe79d0] [c00000000024ab90] .blk_run_queue+0x94/0xec
[c00000000ffe7a70] [c0000000003b3b08] .scsi_run_queue+0x24c/0x27c
[c00000000ffe7b20] [c0000000003b4424] .scsi_next_command+0x48/0x70
[c00000000ffe7bc0] [c0000000003b4b48] .scsi_end_request+0xbc/0xe4
[c00000000ffe7c60] [c0000000003b5294] .scsi_io_completion+0x170/0x3e8
[c00000000ffe7d40] [c0000000003ae0e4] .scsi_finish_command+0xb4/0xd4
[c00000000ffe7dd0] [c0000000003b584c] .scsi_softirq_done+0x114/0x138
[c00000000ffe7e60] [c00000000024af70] .blk_done_softirq+0xa0/0xd0
[c00000000ffe7ef0] [c00000000007a2a0] .__do_softirq+0xa8/0x164
[c00000000ffe7f90] [c000000000027edc] .call_do_softirq+0x14/0x24
[c00000003e183950] [c00000000000bdcc] .do_softirq+0x74/0xc0
[c00000003e1839e0] [c00000000007a450] .irq_exit+0x5c/0xac
[c00000003e183a60] [c00000000000c414] .do_IRQ+0x17c/0x1f4
[c00000003e183b00] [c000000000004c24] hardware_interrupt_entry+0x24/0x28
--- Exception: 501 at .ppc64_runlatch_off+0x28/0x60
LR = .pseries_dedicated_idle_sleep+0xd8/0x1a4
[c00000003e183df0] [c000000000048494]
.pseries_dedicated_idle_sleep+0x78/0x1a4 (unreliable)
[c00000003e183e80] [c00000000001110c] .cpu_idle+0x10c/0x1e8
[c00000003e183f00] [c00000000002b5b0] .start_secondary+0x1b4/0x1d8
[c00000003e183f90] [c0000000000083c4] .start_secondary_prolog+0xc/0x10
ipr: 0:0:3:0: 8150: PCI bus error
ipr: IOASA Dump:
ipr: 00000000: 04418000 009000D0 0006FFD0 00000000
ipr: 00000010: 00000000 00000000 00000000 00000000
ipr: 00000020: 01060000 D0001814 01062A00 000F531E
ipr: 00000030: 00040000 00000000 303800B6 00000000
ipr: 00000040: 00000000 04060000 00CCDDDD AABBCCCC
ipr: 00000050: 0006FFD0 6800FFD0 7FFF0030 B9000010
ipr: 00000060: 40000000 80000800 08200000 000013FE
ipr: 00000070: 00000000 00000000 8C00000E 00000000
ipr: 00000080: 00000000 00000000 00000000 00000000
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: Build breakage on powerpc with 2.6.24-rc6-mm1
From: Greg KH @ 2007-12-24 4:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, akpm, linux-kernel, balbir
In-Reply-To: <20071224134353.c00fc231.sfr@canb.auug.org.au>
On Mon, Dec 24, 2007 at 01:43:53PM +1100, Stephen Rothwell wrote:
> Hi Balbir,
>
> Thanks for the report.
>
> On Mon, 24 Dec 2007 04:11:58 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> >
> > I see the following error with the iseries_veth driver in 2.6.24-rc6-mm1
> >
> > drivers/net/iseries_veth.c: In function ‘veth_init_connection’:
> > drivers/net/iseries_veth.c:818: warning: unused variable ‘rc’
> > drivers/net/iseries_veth.c: In function ‘veth_probe_one’:
> > drivers/net/iseries_veth.c:1086: error: ‘veth_port_ktypeq’ undeclared
> > (first use in this function)
> > drivers/net/iseries_veth.c:1086: error: (Each undeclared identifier is
> > reported only once
> > drivers/net/iseries_veth.c:1086: error: for each function it appears
> > in.)
> > make[2]: *** [drivers/net/iseries_veth.o] Error 1
> > make[1]: *** [drivers/net] Error 2
> > make: *** [drivers] Error 2
Thanks for the report, sorry for the typos, I'll fix up my patch.
> Yeah, that would be
> gregkh-driver-kobject-convert-drivers-net-iseries_vethc-to-use-kobject_init-add_ng.
>
> Hi Greg, do you even build with your patches applied?
For the power architecture, no, I do not. I used to, but my cross-build
box died and I haven't taken the time to set it all up again. For i386
and x86-64 I do build everything, and as that's 99% of the users, it's
usually fine :)
I did start to try to get a s390 cross-build working, but ran out of
time a week or so ago...
> > Here's a patch, compile tested to fix the compilation problem
>
> Hopefully Greg will fix his original patch before it reaches Linus.
I will do that.
thanks,
greg k-h
^ permalink raw reply
* Re: drivers/net/iseries_veth.c dubious sysfs usage
From: Greg KH @ 2007-12-24 5:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, David Gibson, linuxppc-dev, Kyle A. Lucke, paulus
In-Reply-To: <20071224135208.2a29ffc0.sfr@canb.auug.org.au>
On Mon, Dec 24, 2007 at 01:52:08PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Wed, 12 Dec 2007 23:08:29 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > Hm, ok, it's odd as you are the only driver in the whole tree doing
> > something like this, but it seems semi-resonable, so I can't complain :)
> >
> > I'll fix the core up to allow you to do this, thanks for the
> > explanation.
>
> So if this "seems semi-reasonable", why was the result
> gregkh-driver-driver-add-driver_add_kobj-for-looney-iseries_veth-driver
> containing "Hopefully no one uses this function in the future and the
> iseries_veth driver authors come to their senses so I can remove this
> hack..." as part of its comment. If you expect respect, you need to
> treat others the same way ...
Well, sarcasm doesn't come accross very easily in changelog comments it
seems :)
> If what the driver writers are doing is "looney" (in your opinion), then
> please describe a better way of doing what they are trying to do.
> Sometimes, if people have to abuse the infrastructure, it is possible that
> the infrastructure is lacking?
In thinking about this some more, no, I think you all are abusing the
infrastructure here. This is the ONLY driver in the entire kernel tree
that thinks it is acceptable to hang kobjects off of the driver
structure. For some reason, no one else does this either because they
never would think of doing such a thing, or that they are not as unique
as this driver.
So I take back the "semi-resonable" statement above. Please prove to me
that:
- it is ok to hang kobjects off of a driver when:
- no userspace tool will ever be notified that they have
been created
- no known userspace library knows how to find such
attributes (libsysfs can't do that last I looked, and
it's no longer maintained.)
- there is no documentation in the Documentation/ABI/
explaining this usage.
- this can not be just a easily expressed in debugfs, or some
other representation (netlink for configuration, configfs,
some other location in sysfs, a driver-specific filesystem,
etc.)
- that there is a tool out there using this current interface.
I don't like this usage of sysfs as it is very abnormal, and we are
trying very hard to fix up the rough edges here, to:
- make it easier to program to and not get things incorrect
within the kernel
- present a unified, semi-sane interface that is documented well
to userspace so users don't get even madder then they
currently are.
thanks,
greg k-h
^ permalink raw reply
* Re: Loop at starting pid 164, tty '': '/sbin/getty'
From: ramkumarj Ramkumar @ 2007-12-24 9:20 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-embedded
In-Reply-To: <20071224040915.GA20380@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 3628 bytes --]
Hi Olof,
Thanks a lot for replying to the query posted. It works now. Initially I had
created the device file tts/0 instead of ttyS0 and still faced the same
issue. Now I have the ttyS0 created and created tty0 and also modified the
inittab as below,
--------------------------------------------------------------------------
Original Config ( Not Working )
--------------------------------------------------------------------------
::sysinit:/etc/init.d/rcS
#::askfirst:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
::respawn:/sbin/getty 38400 tts/0
Created the following devices in /dev through
mknod -m 660 console c 5 1
mknod -m 660 xsa b 254 0
mknod -m 660 xsa1 b 254 1
mknod -m 660 xsa2 b 254 2
mknod -m 660 xsa3 b 254 3
mkdir tts
cd tts
mknod -m 660 0 b 4 64
cd ..
mknod -m 660 null c 1 3
-------------------------------------------------------------------------
Working Config
-------------------------------------------------------------------------
# cat inittab
::sysinit:/etc/init.d/rcS
#::askfirst:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
::respawn:/sbin/getty -L ttyS0 38400 vt100
Created the following devices in /dev
# ls -al
drwxr-xr-x 5 root root 1024 Jan 1 00:00 .
drwxr-xr-x 17 root root 1024 Dec 21 2007 ..
crw--w--w- 1 root root 5, 1 Jan 1 00:00 console
srw-rw-rw- 1 root root 0 Jan 1 00:00 log
crw-rw---- 1 root root 1, 3 Dec 21 2007 null
drwxr-xr-x 2 root root 1024 Dec 21 2007 pts
drwxr-xr-x 2 root root 1024 Dec 21 2007 shm
drwxr-xr-x 2 root root 1024 Dec 21 2007 tts
crw--w--w- 1 root root 4, 0 Dec 24 2007 tty0
crw------- 1 root root 4, 64 Jan 1 00:12 ttyS0
brw-rw---- 1 root root 254, 0 Dec 21 2007 xsa
brw-rw---- 1 root root 254, 1 Dec 21 2007 xsa1
brw-rw---- 1 root root 254, 2 Dec 21 2007 xsa2
brw-rw---- 1 root root 254, 3 Dec 21 2007 xsa3
#
Now I m able to see the login prompt :) .
I would be very grateful if the following questions could be addressed,
1. Does the inittab format changed for Linux 2.6. The old one was from
mkrootfs (which I think is pretty old). I could see some changes in the
"respawn" line.
2. Is it required to run the tty0 along with ttyS0. Is this is mandatory. I
assumed all these days console and ttyS0 should be sufficient.
3. A very basic question : What is the clear difference between ttyS0 ( UART
Driver ), console and tty0. To my understanding, ttyS0 is the first port
UART 's driver (for 16550/8250) which deals with the hardware as such by
writing and reading the registers. tty0 is virtual console, something to do
with telnet sessions. But I dont clearly understand why console and tty0 are
both required or not. Please correct me if my understanding is wrong.
Merry Christmas.
Thanks and Regards,
Ramkumar
On Dec 24, 2007 12:09 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> On Sat, Dec 22, 2007 at 04:51:16PM +0800, ramkumarj Ramkumar wrote:
>
> > I m trying to run Linux 2.6 ( From Grant) on ML-403. I used the
> > busybox-1.7.2. During booting, I found the following logs and it keeps
> > trying to respawn the getty.It keeps looping and I never see the login
> > prompt. Am I missing something.
> >
> > process '/sbin/getty 38400 tts/0' (pid 163) exited. Scheduling it for
> > restart.
>
> Do you have a /dev/ttys/0? First serial port is normally /dev/ttyS0.
>
>
> -Olof
>
[-- Attachment #2: Type: text/html, Size: 5595 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: Jochen Friedrich @ 2007-12-24 11:01 UTC (permalink / raw)
To: David Gibson; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20071223230342.GA20636@localhost.localdomain>
Hi David,
>> + localbus@8000000 {
>> + compatible = "betaresearch,dbox2-localbus";
>
> Is this bus interface really board specific? I would have thought the
> localbus bridge would have been part of the SoC in which case the
> compatible string should mention the 823 rather than the dbox.
>
>> + #address-cells = <1>;
>
> It's also usual for these localbus things, to have #address-cells of
> 2, with the chipselect explicitly present as the first cell.
The setup of the localbus is already done in the boot loader. However, i'll
recode this to reflect the mapping of addresses to chipselects.
>> + #size-cells = <1>;
>> + reg = <8000000 18000000>;
>> +
>> + ranges = <0 8000000 18000000>;
>> +
>> + enx@0 {
>> + compatible = "c-cube,enx";
>
> What are these mysterious enx, gtx, etc. devices? Some comments might
> be nice.
Those are mostly devices for video processing (MPEG demux, on screen display, MPEG decoder, etc).
Drivers (for ARCH=ppc) are available on cvs.tuxbox.org with GPL license. A work in progress port
to ARCH=powerpc is at git://git.bocc.de/dbox2.git.
>> + // Port D is LCD exclusive. Don't export as GPIO
>> + CPM1_PIO: pio@970 {
>> + compatible = "fsl,cpm1-pario";
>> + reg = <970 180>;
>> + num-ports = <3>;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + lcd@970 {
>> + reg = <970 10>;
>> + compatible = "samsung,ks0713";
>
> Is this representing an LCD controller, or the display itself. Either
> way I'm surprised there's something here in the SoC that has a
> compatible string that's not "fsl,something"
It's a LCD controller wired to PortD. PortD is used for four 1bit lines
and one 8bit bus.
Would something like this be better?
CPM1_PIO: pio@970 {
compatible = "fsl,cpm1-pario";
reg = <970 180>;
num-ports = <4>;
#gpio-cells = <2>;
};
lcd@0 {
compatible = "samsung,ks0713";
gpio-parent = <&CPM1_PIO>;
gpio-port = 3;
}
And then run gpio_request() for all lines on this port in the driver?
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-24 12:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <476DD544.2050807@freescale.com>
On Sat, Dec 22, 2007 at 09:25:56PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >2. QE SCCs (slow UCCs, used as an UARTs)
>
> I a posted a driver that provides this support, I'm just waiting for
> Kumar to apply it.
Yup. I've seen it, thanks. I'm going to test it as well. ;-)
> What revision of the 8360 does this board use?
MPC8360E, Rev: 21. Are you aware of any known issues on this chip
regarding UCC serials?
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-24 12:17 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <476DD5DF.5020806@freescale.com>
On Sat, Dec 22, 2007 at 09:28:31PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >+ qe@e0100000 {
> >+ #address-cells = <1>;
> >+ #size-cells = <1>;
> >+ compatible = "fsl,qe";
> >+ ranges = <0 0xe0100000 0x00100000>;
> >+ reg = <0xe0100000 0x480>;
> >+ /* filled by u-boot */
> >+ brg-frequency = <0>;
>
> You need "bus-frequency" here too
Hm..
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048388.html
^^ David Gibson suggested to get rid of it.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCHv2] powerpc: DBox2 Board Support
From: Arnd Bergmann @ 2007-12-24 12:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <476E9930.6000205@scram.de>
On Sunday 23 December 2007, Jochen Friedrich wrote:
> This patch adds device tree source, default config and setup code for
> DBox2 devices.
Cool stuff. I used to have one of these boxes myself, maybe I should
get one again when it's hitting mainline.
Is this already a complete port, or do you also need some device
drivers or boot wrapper code to go along with it?
> + memory {
> + device_type = "memory";
> + reg = <0 2000000>;
> + };
I thought there are both models with 32MB and 16MB available.
If that's true, shouldn't this be filled out by the boot loader?
> +#
> +# Frame buffer hardware drivers
> +#
> +# CONFIG_FB_OF is not set
> +# CONFIG_FB_VGA16 is not set
> +# CONFIG_FB_S1D13XXX is not set
> +# CONFIG_FB_IBM_GXT4500 is not set
> +# CONFIG_FB_VIRTUAL is not set
> +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
No hardware framebuffer driver? Can't you use
the FB_OF driver by default? I'd guess that a
set-top box without output is rather pointless ;-)
> +# DOS/FAT/NT Filesystems
> +#
> +CONFIG_FAT_FS=y
> +CONFIG_MSDOS_FS=y
> +CONFIG_VFAT_FS=y
> +CONFIG_FAT_DEFAULT_CODEPAGE=437
> +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
> +# CONFIG_NTFS_FS is not set
What media can you connect that use the FAT file system?
I'd guess that if you can get rid of these, you can also
disable the entire block layer, which should free up
some kernel memory.
> @@ -0,0 +1,30 @@
> +/*
> + * A collection of structures, addresses, and values associated with
> + * the DBox2.
> + *
> + * Author: (c) 2007 Jochen Friedrich
> + *
> + * 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.
> + */
> +
> +#ifdef __KERNEL__
> +#ifndef __ASM_DBOX2_H__
> +#define __ASM_DBOX2_H__
You don't need the #ifdef __KERNEL__ any more if you don't have
any user-visible parts in the header. Just leave it out of the
list of exported header files (as you already do).
> +
> +/* Vendor information in BR Bootloader
> + */
> +
> +#define DBOX2_VENDOR_OFFSET (0x1ffe0)
> +
> +enum dbox2_mid {
> + DBOX2_MID_NOKIA = 1,
> + DBOX2_MID_PHILIPS = 2,
> + DBOX2_MID_SAGEM = 3,
> +};
> +
> +enum dbox2_mid dbox2_get_mid(void);
Can you move this functionality from the kernel to the boot wrapper?
It looks like this is something that really belongs into the device
tree.
> +static void __init dbox2_setup_arch(void)
> +{
> + struct device_node *np;
> + static u8 __iomem *config;
> +
> + cpm_reset();
> + init_ioports();
> +
> + /* Enable external IRQs for AVIA chips */
> + clrbits32(&mpc8xx_immr->im_siu_conf.sc_siumcr, 0x00000c00);
This smells like a hack. What are AVIA chips, and shouldn't
their driver enable the IRQs?
> + if (dbox2_manuf_id == DBOX2_MID_NOKIA)
> + np = of_find_node_by_path("/localbus@8000000/enx@0");
> + else
> + np = of_find_node_by_path("/localbus@8000000/gtx@0");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +
> + if (dbox2_manuf_id == DBOX2_MID_PHILIPS)
> + np = of_find_node_by_path("/localbus@8000000/cam@4000000");
> + else
> + np = of_find_node_by_path("/localbus@8000000/cam@4040000");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +}
What is this code for? Why do you want to detach nodes from the device
tree that have been put in there by the boot loader?
> +static struct of_device_id __initdata of_bus_ids[] = {
> + { .name = "soc", },
> + { .name = "cpm", },
> + { .name = "localbus", },
> + {},
> +};
Shouldn't this check for 'compatible' properties instead of 'name'?
> +static int __init declare_of_platform_devices(void)
> +{
> + /* Publish the QE devices */
> + if (machine_is(dbox2))
> + of_platform_bus_probe(NULL, of_bus_ids, NULL);
> +
> + return 0;
> +}
> +device_initcall(declare_of_platform_devices);
This is a candidate for the new platform_initcall stuff.
I also once did a patch that let you have a default 'of_bus_ids'
member in the ppc_md. I never got around to submitting that, but
if there is interest, I can dig it out again.
> --- a/include/asm-powerpc/mpc8xx.h
> +++ b/include/asm-powerpc/mpc8xx.h
> @@ -23,6 +23,10 @@
> #include <platforms/8xx/mpc885ads.h>
> #endif
>
> +#if defined(CONFIG_DBOX2)
> +#include <platforms/8xx/dbox2.h>
> +#endif
> +
Don't hide #includes or platform specific #defines in #ifdef.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: update 440EP(x)/440GR(x) identical PVR issue workaround
From: Valentine Barshak @ 2007-12-24 12:51 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200712212056.41798.sr@denx.de>
Stefan Roese wrote:
> Hi Valentine,
>
> On Friday 21 December 2007, Valentine Barshak wrote:
>>> Good catch. I'll have to look more closely to see if anything else
>>> would be broken by changing the cpu node name from "PowerPC,xxxx@0" to
>>> "cpu@0".
>>>
>>> josh
>> Looks like we need a u-boot update for 405Ex Kilauea board.
>> Mine (U-Boot 1.3.0-rc3-gccc2fe86-dirty (Oct 25 2007 - 12:18:41))
>> fails to boot with new cpu node changes:
>>
>> Uncompressing Kernel Image ... OK
>> Booting using the fdt at 0x400000
>> le to update property /cpus/PowerPC,405EX@0:timebase-frequency,
>> err=FDT_ERR_NOTFOUND
>> Unable to update property /cpus/PowerPC,405EX@0:clock-frequency,
>> err=FDT_ERR_NOTFOUND
>
> Already done. :) Please take a look at the current implementation in the
> for-1.3.2 branch of the u-boot-ppc4xx custodian repo:
>
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-ppc4xx.git;a=shortlog;h=for-1.3.2
>
> This works for both cpu node names.
Great, thanks :)
Valentine.
>
> Best regards,
> Stefan
^ permalink raw reply
* Re: [PATCH 1/21] [POWERPC] Reworking machine check handling and Fix 440/440A
From: Josh Boyer @ 2007-12-24 16:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071223193210.1d06f33f@zod.rchland.ibm.com>
On Sun, 23 Dec 2007 19:32:10 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Fri, 21 Dec 2007 15:39:21 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Index: linux-merge/arch/powerpc/kernel/traps.c
> > ===================================================================
> > --- linux-merge.orig/arch/powerpc/kernel/traps.c 2007-12-20 11:34:43.000000000 +1100
> > +++ linux-merge/arch/powerpc/kernel/traps.c 2007-12-20 11:35:40.000000000 +1100
>
> [snip]
>
> > -#elif defined (CONFIG_E500)
> > + return 0;
> > +}
> > +#elif defined(CONFIG_E500)
> > +int machine_check_e500(struct pt_regs *regs)
>
> This...
>
> > +{
> > + unsigned long reason = get_mc_reason(regs);
> > +
> > printk("Machine check in kernel mode.\n");
> > printk("Caused by (from MCSR=%lx): ", reason);
> >
> > @@ -403,7 +416,14 @@ static int generic_machine_check_excepti
> > printk("Bus - Instruction Parity Error\n");
> > if (reason & MCSR_BUS_RPERR)
> > printk("Bus - Read Parity Error\n");
> > -#elif defined (CONFIG_E200)
> > +
> > + return 0;
> > +}
> > +#elif defined(CONFIG_E200)
> > +int machine_check_e200(struct pt_regs *regs)
>
> ... and this cause build failures for most of the mpc8xxx defconfigs.
> The reason is that e200 and e500 are both lumped under CONFIG_FSL_BOOKE
> in cputable.c, but you have them segregated more here. I've added a
> fix that just does CONFIG_FSL_BOOKE here to match cputable.c.
Actually, reverse that. There are other places where e200 and e500 are
separated by ifdefs, so I made cputable.c match the rest.
josh
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: Kumar Gala @ 2007-12-24 16:53 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <476D61DB.2090201@scram.de>
>
> diff --git a/include/asm-powerpc/mpc8xx.h b/include/asm-powerpc/
> mpc8xx.h
> index 2be014b..b6fd7d6 100644
> --- a/include/asm-powerpc/mpc8xx.h
> +++ b/include/asm-powerpc/mpc8xx.h
> @@ -23,6 +23,10 @@
> #include <platforms/8xx/mpc885ads.h>
> #endif
>
> +#if defined(CONFIG_DBOX2)
> +#include <platforms/8xx/dbox2.h>
> +#endif
> +
> #ifdef CONFIG_PCMCIA_M8XX
> extern struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
> #endif
is this really needed? if so why. we should work towards not having
to do this going forward.
(I cant believe its needed since dbox2.h doesn't seem to have anything
defined we'd need anywhere else).
- k
^ permalink raw reply
* Re: [PATCH] Add information on enabling sound on the MPC8641 HPCN
From: Timur Tabi @ 2007-12-24 17:24 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071223152613.GA4817@lixom.net>
Olof Johansson wrote:
> Sounds like a board rework document on your support site is the right
> place for this.
Except that no one would know to look there. I don't even know who to
contact to get that kind of information on that site.
> We normally don't document board reworks required in
> the linux sources, do we?
I do, if I can find a discrete place for it. The patch for my QE UART
driver has a similar comment in the DTS for the 8323E MDS.
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Timur Tabi @ 2007-12-24 17:39 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, david
In-Reply-To: <20071224121715.GB7903@localhost.localdomain>
Anton Vorontsov wrote:
>> You need "bus-frequency" here too
>
> Hm..
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048388.html
>
> ^^ David Gibson suggested to get rid of it.
It looks to me like he's just suggesting that we rename it to
clock-frequency. That may be a better name, but for now changing it
will only confuse U-Boot and any other code that's looking for
bus-frequency. If we want to rename it, I suggest we do that in a
different patch. Having some DTS files with "bus-frequency" and others
with "clock-frequency" is bad.
^ permalink raw reply
* Re: Build breakage on powerpc with 2.6.24-rc6-mm1
From: Olof Johansson @ 2007-12-24 19:27 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, akpm, balbir, linux-kernel, linuxppc-dev
In-Reply-To: <20071224044912.GA10690@suse.de>
On Sun, Dec 23, 2007 at 08:49:12PM -0800, Greg KH wrote:
> > Hi Greg, do you even build with your patches applied?
>
> For the power architecture, no, I do not. I used to, but my cross-build
> box died and I haven't taken the time to set it all up again.
Crosstool makes it really easy. It's demo-powerpc-970.sh will build a
toolchain that can build both 32- and 64-bit powerpc kernels. It's got
a demo-s390.sh as well, but I haven't tried that one myself.
-Olof
^ permalink raw reply
* Re: Loop at starting pid 164, tty '': '/sbin/getty'
From: Olof Johansson @ 2007-12-24 19:38 UTC (permalink / raw)
To: ramkumarj Ramkumar; +Cc: linuxppc-embedded
In-Reply-To: <4f8c3030712240120m30d68b37g8b5f099294c6d769@mail.gmail.com>
Hi,
On Mon, Dec 24, 2007 at 05:20:10PM +0800, ramkumarj Ramkumar wrote:
> I would be very grateful if the following questions could be addressed,
>
> 1. Does the inittab format changed for Linux 2.6. The old one was from
> mkrootfs (which I think is pretty old). I could see some changes in the
> "respawn" line.
Inittab isn't tied to the kernel, but to the init process. So no, it
should not have changed between 2.4 and 2.6.
> 2. Is it required to run the tty0 along with ttyS0. Is this is mandatory. I
> assumed all these days console and ttyS0 should be sufficient.
tty0 is normally one of the vga consoles. It shouldn't be needed if all
you have is serial.
> 3. A very basic question : What is the clear difference between ttyS0 ( UART
> Driver ), console and tty0. To my understanding, ttyS0 is the first port
> UART 's driver (for 16550/8250) which deals with the hardware as such by
> writing and reading the registers. tty0 is virtual console, something to do
> with telnet sessions. But I dont clearly understand why console and tty0 are
> both required or not. Please correct me if my understanding is wrong.
ttyS<x> are normally 8250-compatible uarts, yes. pts/<x> is remote
connections such as telnet or ssh-based ones. tty<x> are normally the
local vga consoles.
-Olof
^ permalink raw reply
* i2c device for a linux 2.6 in XUPV2P
From: Josep Maria Batlle @ 2007-12-24 21:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
Hi all,
I have booted up linux 2.6 on Xilinx XUPV2P (using the base of ml300 config
file).
Now I am trying to use the i2c in the user-space. First of all: is it
possible?
My first attempts have not worked. I have made this:
1) I enable "I2C Support" and "I2C device interface" in the kernel
recompilation.
2) I added the "i2c-0" device in /dev (# mknod i2c-0 c 89 0)
3) then I run a simple program to open the device (provided by the
"dev-interface" file of i2c kernel documentation) that returns this errno
message: "No such device".
I have tried to use the device number 1, 2, 3, 4 but these have not worked.
I have tried to use the device "i2cn" but not worked. I have tried to use
all the BSP's from the EDK (7.1i) and then only the "xparameters_ml300.h" in
the compilation. After all of this, now I am modifying the RFS for "mdev"...
Somebody can tell me what I am doing wrong if this use is possible?
I use the kernel tree "virtex-for-2.6.24" from SecretLab and Busybox 1.7.2.
Thanks.
[-- Attachment #2: Type: text/html, Size: 1142 bytes --]
^ permalink raw reply
* Re: [PATCH] Add information on enabling sound on the MPC8641 HPCN
From: Olof Johansson @ 2007-12-24 23:10 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <476FEB43.8050507@freescale.com>
On Mon, Dec 24, 2007 at 11:24:19AM -0600, Timur Tabi wrote:
> Olof Johansson wrote:
>
> > Sounds like a board rework document on your support site is the right
> > place for this.
>
> Except that no one would know to look there.
Why do you expect people to look at the device tree source file instead?
It seems even more remote to me.
> I don't even know who to contact to get that kind of information on
> that site.
That's a pretty lame excuse. :)
> > We normally don't document board reworks required in
> > the linux sources, do we?
>
> I do, if I can find a discrete place for it. The patch for my QE UART
> driver has a similar comment in the DTS for the 8323E MDS.
Are freescale customers really used to going to the linux device tree
sources to find out how to modify their boards to achieve certain
functionality with their eval boards?! I guess you guys are taking the
"device trees are used to describe the hardware" statement to it's
fullest extent.
-Olof
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: David Gibson @ 2007-12-25 1:04 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <476F918F.4050909@scram.de>
On Mon, Dec 24, 2007 at 12:01:35PM +0100, Jochen Friedrich wrote:
> Hi David,
>
> >> + localbus@8000000 {
> >> + compatible = "betaresearch,dbox2-localbus";
> >
> > Is this bus interface really board specific? I would have thought the
> > localbus bridge would have been part of the SoC in which case the
> > compatible string should mention the 823 rather than the dbox.
> >
> >> + #address-cells = <1>;
> >
> > It's also usual for these localbus things, to have #address-cells of
> > 2, with the chipselect explicitly present as the first cell.
>
> The setup of the localbus is already done in the boot loader. However, i'll
> recode this to reflect the mapping of addresses to chipselects.
Sure, that's normal. But to the greatest extent possible, the device
tree should describe the hardware, not the configuration that's been
set up by the firmware/bootloader. It's usually not possible to get
all the way there, but encoding the chipselect information this way
gets you closer. It means that if you later need to adapt the device
tree to the same board with a firmware that does things differently,
only the "ranges" property should need changing. Or, if you later
need a kernel port to a version with no-firmware or minimal firmware
that doesn't configure the bus, the necessary information is in the
tree to configure the bridge.
> >> + #size-cells = <1>;
> >> + reg = <8000000 18000000>;
> >> +
> >> + ranges = <0 8000000 18000000>;
> >> +
> >> + enx@0 {
> >> + compatible = "c-cube,enx";
> >
> > What are these mysterious enx, gtx, etc. devices? Some comments might
> > be nice.
>
> Those are mostly devices for video processing (MPEG demux, on screen display, MPEG decoder, etc).
> Drivers (for ARCH=ppc) are available on cvs.tuxbox.org with GPL license. A work in progress port
> to ARCH=powerpc is at git://git.bocc.de/dbox2.git.
Ok. Again, some comments so a casual read of the tree tells you
roughly what they are would be nice.
> >> + // Port D is LCD exclusive. Don't export as GPIO
> >> + CPM1_PIO: pio@970 {
> >> + compatible = "fsl,cpm1-pario";
> >> + reg = <970 180>;
> >> + num-ports = <3>;
> >> + #gpio-cells = <2>;
> >> + };
> >> +
> >> + lcd@970 {
> >> + reg = <970 10>;
> >> + compatible = "samsung,ks0713";
> >
> > Is this representing an LCD controller, or the display itself. Either
> > way I'm surprised there's something here in the SoC that has a
> > compatible string that's not "fsl,something"
>
> It's a LCD controller wired to PortD. PortD is used for four 1bit lines
> and one 8bit bus.
I'm still kind of confused here. Does the pio@970 node above
represent the PortD controller? If the LCD controller is accessed
solely through PortD, then it should be a child of the PortD node.
At present, pio and lcd have overlapping reg resources which is
certainly wrong.
--
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
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