* Re: Refactor booting-without-of.txt
From: Grant Likely @ 2007-10-16 17:17 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, microblaze-uclinux
In-Reply-To: <20071016171417.64605230209@mail24-fra.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> On a similar note, is there interest in actually factoring the device
> tree code out from the different architectures into a common codebase?
It's already happened somewhat. (Look in drivers/of and include/linux/of*.h)
However, I don't think any of the stuff specific to flattened device
trees is being factored out of arch/powerpc yet.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: Refactor booting-without-of.txt
From: Stephen Neuendorffer @ 2007-10-16 17:24 UTC (permalink / raw)
To: David Gibson, Grant Likely
Cc: Olof Johansson, linuxppc-dev, microblaze-uclinux
In-Reply-To: <20071016032415.GO26787@localhost.localdomain>
=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.or
> g=20
> [mailto:linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@o
zlabs.org] On Behalf Of David Gibson
> Sent: Monday, October 15, 2007 8:24 PM
> To: Grant Likely
> Cc: Olof Johansson; linuxppc-dev; microblaze-uclinux@itee.uq.edu.au
> Subject: Re: Refactor booting-without-of.txt
>=20
> On Mon, Oct 15, 2007 at 09:02:09PM -0600, Grant Likely wrote:
> > On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > > On Mon, Oct 15, 2007 at 11:14:44AM -0600, Grant Likely wrote:
> > > > On 10/15/07, Olof Johansson <olof@lixom.net> wrote:
> > > > > On Mon, Oct 15, 2007 at 10:08:44AM -0600, Grant Likely wrote:
> > > > > > Adding the Linux expected device tree bindings to
> > > > > > booting-without-of.txt seems to be getting a little=20
> unwieldy. Plus
> > > > > > with more than one arch using the device tree=20
> (powerpc, sparc &
> > > > > > microblaze) the device tree bindings aren't=20
> necessarily powerpc only
> > > > > > (the Xilinx devices certainly fall in this category).
> > > > > >
> > > > > > Anyone have comments about splitting the expected=20
> device tree bindings
> > > > > > out of booting-without-of.txt into a separate directory?
> > > > >
> > > > > The flat device tree is, in spite of what some people=20
> would like it to be,
> > > > > not open firmware, nor is it the same as their=20
> bindings. So I think we'd
> > > > > be doing ourselves a disservice by continuing to=20
> associate them together.
> > > > > All it would take is a rename of the directory,=20
> unfortunately i don't
> > > > > have any suggestions on better names though.
> > > >
> > > > I think I need to stick with the of prefix. All the=20
> support API in
> > > > include/linux/of_* is prefixed with "of_" already, so=20
> convention is
> > > > established.
> > > >
> > > > How about Documentation/of-device-tree?
> > >
> > > It seems a little counterintuitive to change names from "booting
> > > *without* of" to "of *"...
> >=20
> > Heh; true. The *only* reason I think it should be=20
> 'of-<anything>' is
> > because *all* the support APIs are named that way. I'll happily use
>=20
> No, not all, just most...
>=20
> And do bear in mind that a lot of those accessor functions are at
> least valid both on of and flat-tree systems.
>=20
> > another name if I get the impression that most of us in our little
> > group think it should be something else.
> >=20
> > Cheers,
> > g.
> >=20
> >=20
>
How about just 'device-tree', referring to any source, and then
of-device-tree and flat-device-tree to document how the device tree is
constructed.
The fact that the API is poorly named is something that can always be
fixed (and perhaps should be earlier rather than later).
Steve
^ permalink raw reply
* Re: [UNTESTED PATCH v2] 8xx: Convert mpc866ads to the new device binding.
From: Scott Wood @ 2007-10-16 17:55 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071016215308.764d9922@vitb.ru.mvista.com>
Vitaly Bordug wrote:
> Hi Scott,
>
> orig one does not build (not your issue apparently):
>
> CC drivers/net/fs_enet/fs_enet-main.o
> drivers/net/fs_enet/fs_enet-main.c: In function `fs_enet_probe':
> drivers/net/fs_enet/fs_enet-main.c:1252: error: implicit declaration of
> function `SET_MODULE_OWNER'
> drivers/net/fs_enet/fs_enet-main.c:1292: error: structure has no member
> named `poll'
> drivers/net/fs_enet/fs_enet-main.c:1293: error: structure has no member
> named `weight'
> make[3]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1
> make[2]: *** [drivers/net/fs_enet] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
>
> because net_device does not have 'poll' and 'weight' anymore.
>
> Moreover, with the patch, it does not seem to boot(with upper lines commented out to get it build). I'm investigating the reason right now.
Yeah, I was working on cleaning up the mess when I got this message. :-)
Removing the napi_enable call should make it boot. I'm now trying to
get in to work with napi enabled...
-Scott
^ permalink raw reply
* RE: Linux booting problem on Xilinx ppc
From: aauer1 @ 2007-10-16 18:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000901c81006$7303b490$bb3ca688@LGE.NET>
The on-chip memories are disabled. Only the BRAM is enabled. Now, we also use
the ELDK 4.1 from Denx and the included cross compiler. The result is the
same... the Kernel stops at "Now booting the kernel". Now, we also have an
USB JTAG cable. So, we can debug the memory.
Probably, anyone has another idea.
Thanks,
Andreas
Sergey Oleynichenko wrote:
>
>
> I noticed this problem happens when on-chip memories are enabled in a
> design
> (it is 4th page in base system builder). Try to leave them "none" for both
> instruction and data.
>
> Sergey
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+soleynichenko=zenith.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+soleynichenko=zenith.com@ozlabs.org] On
> Behalf Of aauer1
> Sent: Monday, October 15, 2007 1:47 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux booting problem on Xilinx ppc
>
>
> Hello
>
> I'm also working with ML403 board from Xilinx and have the same problem as
> you. The boot process stops after decompressing with the message "Now
> booting the kernel". We also used gcc-4.1.0 for the cross compilation. So,
> I
> would be glad to know, which gcc version have you used to get a working
> kernel!
>
> Thanks,
> Andreas
>
>
>
> Junqiang Hu wrote:
>>
>>
>> Hi Grant,
>>
>> Thank you so much for the reply! Fortunately I got it work now --
>> it's
>> the crosstool compiler problem. Originally I was using gcc-4.1.0, yet
>> when compiling kernel 2.6.22, I noticed that it says gcc-4.1.0 will
>> miscompile the kernel, so I changed to another version, and now I can let
>> it go!
>>
>> Right now still not fully booted because of the SystemACE problem, or
>> maybe the partition is not correct. I'm still working on it, hopefully
>> to
>> get it solved soon :-)
>>
>> Thanks,
>> -J.
>>
>>
>> Grant Likely-2 wrote:
>>>
>>> On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
>>>>
>>>>
>>>> Dear friends,
>>>>
>>>> I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
>>>> board. The Linux version I'm using is 2.4; the cross-compiler is
>>>> gcc-4.1.0, glibc 2.3.6. When booting the kernel, it shows:
>>>> loaded at: 00400000 004B51E4
>>>> board data at: 00000000 00000018
>>>> relocated to: 0040526C 00405284
>>>> zimage at: 00405B2B 004B177C
>>>> avail ram: 004B6000 60000000
>>>
>>> I strongly recommend moving to a 2.6 kernel. Recent mainline has
>>> support for the Xilinx ppc built in.
>>>>
>>>> Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3
>>>> rw
>>>> Uncompressing Linux...done.
>>>> Now booting the kernel
>>>>
>>>> Then it hangs. First it seems to me that the "avail ram" is not
>>>> correct,
>>>> since I configured only 32MB SDRAM. Moreover, if it's first powered
>>>> on,
>>>> the
>>>> end address of "avail ram" would be FFD9FBED. Then I tried to
>>>> investigate
>>>> the problem using xmd. When launched, it says:
>>>
>>> (If you're using u-boot) You might have a mismatch between the board
>>> info structure used by u-boot and the one used by Linux.
>>>
>>> Also, you should use your debugger to inspect the __log_buf memory of
>>> the kernel. A common problem is the kernel starts booting, but the
>>> console is setup incorrectly and so you see nothing. But, you can
>>> read the console output directly from memory if you look at the
>>> __log_buf region (find the address in the System.map file; you might
>>> need to subtract 0xC0000000 from the address to view the memory)
>>>
>>> Cheers,
>>> g.
>>>
>>> --
>>> Grant Likely, B.Sc., P.Eng.
>>> Secret Lab Technologies Ltd.
>>> grant.likely@secretlab.ca
>>> (403) 399-0195
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13
> 219154
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13239003
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* current -git adbhid.c build error
From: Joseph Fannin @ 2007-10-16 18:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dmitry Torokhov
Hello.
Commit b981d8b3f5e008ff10d993be633ad00564fc22cd in Linus's git tree
did this:
@@ -374,9 +373,9 @@ adbhid_input_keycode(int id, int scancode, int repeat)
#endif /* CONFIG_PPC_PMAC */
}
- if (adbhid[id]->keycode[keycode]) {
- input_report_key(adbhid[id]->input,
- adbhid[id]->keycode[keycode],
adbhid[id]->!up_flag);
+ key = adbhid[id]->keycode[keycode];
+ if (key) {
+ input_report_key(adbhid[id]->input, key, !up_flag);
input_sync(adbhid[id]->input);
} else
printk(KERN_INFO "Unhandled ADB key (scancode %#02x)
%s.\n", keycode,
... but did not define "key":
drivers/macintosh/adbhid.c: In function ‘adbhid_input_keycode’:
drivers/macintosh/adbhid.c:376: error: ‘key’ undeclared (first use in this function)
Gitweb says something about a merge conflict in this file, so maybe
Linus did this, and not Dmitry?
I'll leave it up to someone else to decide how best this variable
should be defined.
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply
* RE: [PATCH v2] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-16 18:24 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, Wolfgang Reissnegger, Leonid,
microblaze-uclinux
In-Reply-To: <20071015155223.7403.39615.stgit@trillian.cg.shawcable.net>
> + n) Xilinx EMAC and Xilinx TEMAC
> +
> + Xilinx Ethernet devices. Uses common properties from=20
> other Ethernet
> + devices with the following constraints:
> + =20
> + Required properties:
> + - compatible : Must include one of: "xilinx,plb-temac",
> + "xilinx,plb-emac", "xilinx-opb-emac"
> + - dma-mode : Must be one of "none", "simple", "sg" (sg=20
> =3D=3D scatter gather)
I think it's going to be a significant headache to remap things like the
dma-mode from the xilinx configurations to something else, and then
interpret them correctly in the drivers.
Although it lacks a bit in style, perhaps, I'd greatly prefer having
something like:
Ethernet_MAC {
xilinx,C_DMA_PRESENT =3D <1>;
...
}
(which happens to correspond to "none" above)
DMA mode is perhaps a bad example, since the Xilinx EDK encoding for
this is so unnecessarily obfuscated, but I'd like to avoid setting
precedent for defining a new set of parameterizations here. In the long
term, I'm afraid this will just be an added source of confusion and more
code to maintain.
Steve
^ permalink raw reply
* Describing devices in the device tree
From: Alan Bennett @ 2007-10-16 18:36 UTC (permalink / raw)
To: linuxppc-dev
I'm using a modified ep8248e.dts to describe my hardware and I want to
enable the use of 3 standard interrupts.
1. irq5
2. timer1
3. timer2
How bad does this look?
soc --> cpm -->
timer {
device_type = "timer";
compatible = "fsl,mpc8248-timer";
interrupts = <c 8 d 8>;
interrupt-parent = <&PIC>;
};
irq5 {
device_type = "irq5";
compatible = "fsl,mpc8248-irq5";
interrupts = <17 8>;
interrupt-parent = <&PIC>;
};
-Alan
^ permalink raw reply
* Re: [UNTESTED PATCH v2] 8xx: Convert mpc866ads to the new device binding.
From: Vitaly Bordug @ 2007-10-16 17:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071008224847.GA4053@loki.buserror.net>
Hi Scott,
orig one does not build (not your issue apparently):
CC drivers/net/fs_enet/fs_enet-main.o
drivers/net/fs_enet/fs_enet-main.c: In function `fs_enet_probe':
drivers/net/fs_enet/fs_enet-main.c:1252: error: implicit declaration of
function `SET_MODULE_OWNER'
drivers/net/fs_enet/fs_enet-main.c:1292: error: structure has no member
named `poll'
drivers/net/fs_enet/fs_enet-main.c:1293: error: structure has no member
named `weight'
make[3]: *** [drivers/net/fs_enet/fs_enet-main.o] Error 1
make[2]: *** [drivers/net/fs_enet] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
because net_device does not have 'poll' and 'weight' anymore.
Moreover, with the patch, it does not seem to boot(with upper lines commented out to get it build). I'm investigating the reason right now.
On Mon, 8 Oct 2007 17:48:47 -0500
Scott Wood <scottwood@freescale.com> wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Whoops, forgot the localbus node last time.
>
> arch/powerpc/boot/dts/mpc866ads.dts | 137 +++++++------
> arch/powerpc/platforms/8xx/Kconfig | 1 +
> arch/powerpc/platforms/8xx/mpc86xads.h | 44 ----
> arch/powerpc/platforms/8xx/mpc86xads_setup.c | 289 +++++++-------------------
> 4 files changed, 156 insertions(+), 315 deletions(-)
>
[...]
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Stephen Hemminger @ 2007-10-16 18:53 UTC (permalink / raw)
To: benh; +Cc: netdev, Dreier, Roland, David S. Miller, linuxppc-dev list
In-Reply-To: <1192513792.19073.23.camel@pasglop>
On Tue, 16 Oct 2007 15:49:52 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> net: Add __napi_sycnhronize() to sync with napi poll
>
> The EMAC driver which needs to handle multiple devices with one
> NAPI instance implements its own per-channel disable bit. However,
> when setting such a bit, it needs to synchronize with the poller
> (that is make sure that any pending poller instance has completed,
> or is started late enough to see that disable bit).
>
> This implements a low level __napi_synchronize() function to acheive
> that. The underscores are to emphasis the low level aspect of it and
> to discourage driver writers who don't know what they are doing to
> use it (to please DaveM :-)
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> (Use correct address for Stephen this time)
>
> If the approach is accepted, I would like to have this merged now
> so the EMAC patch to make it work again can follow :-)
>
> Note: I use msleep_interruptible(1); just like napi_disable(). However
> I'm not too happy that the "hot" loop that results of a pending signal
> here will spin without even a cpu_relax ... what do you guys think would
> be the best way to handle this ?
So this is really just like synchronize_irq()? Using msleep is bogus
because you want to spin, you are only waiting for a softirq on the other
cpu to finish. If you wait for a whole millisecond and sleep that
is far longer than the napi routine should take.
You could even optimize it like synchronize_irq() for the non-SMP case.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: cross compilation issue
From: Wolfgang Denk @ 2007-10-16 19:07 UTC (permalink / raw)
To: Leisner, Martin
Cc: linuxppc-embedded,
linuxppc-embedded-bounces+ravi.rao=rflelect.com
In-Reply-To: <556445368AFA1C438794ABDA8901891C0750DDF0@USA0300MS03.na.xerox.net>
Dear Martin,
in message <556445368AFA1C438794ABDA8901891C0750DDF0@USA0300MS03.na.xerox.net> you wrote:
>
> #! /bin/bash
>
> exec make ARCH=powerpc CROSS_COMPILE=/opt/denx/eldk4.1/usr/bin/ppc_74xx- INSTALL_MOD_PATH=${PWD}/root $*
Note that this is *NOT* a suppoted value for CROSS_COMPILE. Please set
your PATH to include the /opt/denx/eldk4.1/usr/bin directory, and set
CROSS_COMPILE=ppc_74xx-
> I know hardhat linux had a strategy to make . files hiding the names of ARCH/CROSS_COMPILE -- so typing make
> would work once configured...
>
> IMHO it should be hardcoded in the Makefile after configuration -- it causes a lot of grief if you FORGET
> to specify one of these and just type "make".
I disagree. Such an approach will hit you as soon as you run a command
not from "make", but from the command line.
Instead, please set and export thse variables in your shell
environment, where each tool can pick it up.
If you have to switch environments frequently you can use some shell
functions to do so. For example, ELDK 4.1 which you use comes with
the "eldk_init" script ("/opt/denx/eldk4.1/eldk_init" in your
installation) which can be "sourced" from the shell like this:
$ source /opt/denx/eldk4.1/eldk_init 74xx
ARCH=ppc
CROSS_COMPILE=ppc_74xx-
DEPMOD=/opt/denx/eldk4.1/usr/bin/depmod.pl
PATH=/opt/denx/eldk4.1/usr/bin:/opt/denx/eldk4.1/bin: ...
$
ELDK 4.2 will use a much cleverer script "eldk-switch" which allows
to select versions and board like this:
-> eldk-switch -r4.1 sequoia
[ sequoia is using PPC440EPx ]
Setup for ppc_4xxFP (using ELDK 4.1)
-> eldk-switch -r4.2 TQM8540
[ TQM8540 is using MPC8540 ]
Setup for ppc_85xx (using ELDK 4.2)
-> eldk-switch -r4.0 MPC860
Setup for ppc_8xx (using ELDK 4.0)
-> eldk-switch MPC7448
Setup for ppc_74xx (using ELDK 4.2)
> One of the things I want to do is look at how the linux make system works now (I recall at times I edit the Makefile
> to hardcode these things).
Never edit the Makefile - this is always a Bad Thing (TM) to do.
Make sure to either set the ARCH and CROSS_COMPILE ariables in your
environment (this is IMHO the more convenient way) or pass them on
the make command line.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Wenn Du ein' weise Antwort verlangst, Mußt Du vernünftig fragen.
-- Goethe, Invektiven
^ permalink raw reply
* vga16fb doesn't build on powerpc (vgacon_remap_base)
From: Joseph Fannin @ 2007-10-16 19:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-fbdev-devel
vga16fb is an available config option on powerpc, but it won't link
with my .config:
ERROR: "vgacon_remap_base" [drivers/video/vga16fb.ko] undefined!
I'm guessing this is because include/asm-powerpc/vga.h declares
vgacon_remap_base:
extern unsigned long vgacon_remap_base;
...but arch/powerpc/kernel/setup_32.c wraps the definition in an #ifdef:
#ifdef CONFIG_VGA_CONSOLE
unsigned long vgacon_remap_base;
EXPORT_SYMBOL(vgacon_remap_base);
#endif
So CONFIG_VGA_CONSOLE=n and CONFIG_FB_VGA16=[y|m] won't work.
I've also noticed that the only places in the tree that ever assign
anything to config_remap_base are under arch/ppc. And
include/asm-powerpc/vga.h also does this:
#ifdef __powerpc64__
#define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
#else
#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
#endif
So VGACON probably doesn't work either on 32bit. I'm guessing arch/powerpc
doesn't support PREP.
How best could this be fixed up? Or should I just let the thing
be? This is obviously not a new thing, and I don't have any hardware
that supports this stuff either.
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Jean Delvare @ 2007-10-16 19:19 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Stefan Roese, i2c, David Gibson
In-Reply-To: <fa686aa40710152121o2fe0d7c9m156170901fd3bf98@mail.gmail.com>
On Mon, 15 Oct 2007 22:21:38 -0600, Grant Likely wrote:
> On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > In fact I think it may be acceptle to do the idx++ thing in this
> > situation. Bus numbers are ugly, but it's not the worst ugliness in
> > the horrible mess that is the Linux i2c subsystem. It means that bus
> > numbers are theoretically unstable, but that's increasingly true of
> > devices of all sorts - it's up to udev to assign meaningful labels at
> > the user level.
David, after such a rant against the Linux i2c subsystem, I sure hope
that you're going to contribute patches to make it better (whatever you
think needs to be improved, as you didn't say.)
> I think the real problem here comes into play when there are 2 types
> of i2c busses in the system. If they both maintain their own idx++
> values; then they will conflict. If an auto assigned bus number is
> used; then it needs to be assigned by the i2c infrastructure; not by
> the driver.
Very true. If you aren't going to define the i2c bus numbers at
platform data level, then you shouldn't be defining them _at all_.
Don't use i2c_add_numbered_adapter, use i2c_add_adapter and let
i2c-core choose an appropriate a bus number.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH v2] pasemi: process i2c device tree entries at boot
From: Scott Wood @ 2007-10-16 16:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071016001701.GA25444@lixom.net>
Olof Johansson wrote:
> On Mon, Oct 15, 2007 at 05:54:51PM -0500, Scott Wood wrote:
>> Olof Johansson wrote:
>>> Setup i2c_board_info based on device tree contents. This has to be
>>> a device_initcall since we need PCI to be probed by the time we
>>> run it, but before the actual driver is initialized.
>> Can we factor at least some of this stuff out into common code?
>
> I didn't really feel strong motivations to do so, given that the amount
> of shared code is quite small, and the official bindings are not yet
> determined.
Enh... I'm just irked because I originally did it in a generic manner,
and whoever it was that did further work on my patch shoved in into
fsl_soc. :-P
> Chances are whenever the bindings are done they might be incompatible
> with what we already have in our firmware, so the code would need to be
> separated out again.
Well, then it'd be better to just have one bit of code to fix, right? :-)
It'd suck to see different i2c controllers end up implementing the
binding differently due to the forking, though. Already with this
patch, we have a different set of i2c devices that will be recognized
depending on the adapter.
-Scott
^ permalink raw reply
* RE: cross compilation issue
From: Leisner, Martin @ 2007-10-16 19:34 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-embedded,
linuxppc-embedded-bounces+ravi.rao=rflelect.com
In-Reply-To: <20071016190750.224A3242E9@gemini.denx.de>
Wolfgang,
I disagree vehemently with "modifying" you session to suit the platform.
This becomes a problem when cross-platforms > 1. When I "set the PATH =
and
environment variables" I have the same problem -- I go to a different=20
platform, type make and get bad results. =20
Why is modifying the makefile a "bad thing?" hardhat did it, and =
afterwards
the cross-compile/arch becomes painless and transparent. Building ways =
to=20
construct software with fewer chances of human error is IMHO a "good =
thing".
I tend to lock down my source tree, and have a link tree for each =
platform.
So I'm not changing my build parameters, hard coding these things in the =
makefile
becomes a "set and forget" operation.
I agree with "problems" running from command lines...I often link in=20
special tools into ~/bin so I can find them (instead of modifying my =
path).
But I can go weeks without having to run a tool from the command line, =
make's I run daily.
Having to "source" a script is another thing you can "forget" to do.
I often "forget" to run my 'make-line' script, and when I quickly hit =
<cntl>-C I don't
have problems (but sometimes I do).
marty
PS:
To cross developers, its VERY handy to build a copy of binutils which =
support multiple=20
architectures -- so the
only thing which is really platform dependent is gas...so my host =
nm/objcopy/objdump/ld
supports all the platforms I'm working on...
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Tue 10/16/2007 3:07 PM
To: Leisner, Martin
Cc: ravi.rao@rflelect.com; avenkatesh@hcl.in; =
linuxppc-embedded-bounces+ravi.rao=3Drflelect.com@ozlabs.org; =
linuxppc-embedded@ozlabs.org
Subject: Re: cross compilation issue
=20
Dear Martin,
in message =
<556445368AFA1C438794ABDA8901891C0750DDF0@USA0300MS03.na.xerox.net> you =
wrote:
>=20
> #! /bin/bash
>=20
> exec make ARCH=3Dpowerpc =
CROSS_COMPILE=3D/opt/denx/eldk4.1/usr/bin/ppc_74xx- =
INSTALL_MOD_PATH=3D${PWD}/root $*
Note that this is *NOT* a suppoted value for CROSS_COMPILE. Please set
your PATH to include the /opt/denx/eldk4.1/usr/bin directory, and set
CROSS_COMPILE=3Dppc_74xx-=20
> I know hardhat linux had a strategy to make . files hiding the names =
of ARCH/CROSS_COMPILE -- so typing make
> would work once configured...
>=20
> IMHO it should be hardcoded in the Makefile after configuration -- it =
causes a lot of grief if you FORGET
> to specify one of these and just type "make".
I disagree. Such an approach will hit you as soon as you run a command
not from "make", but from the command line.
Instead, please set and export thse variables in your shell
environment, where each tool can pick it up.
If you have to switch environments frequently you can use some shell
functions to do so. For example, ELDK 4.1 which you use comes with
the "eldk_init" script ("/opt/denx/eldk4.1/eldk_init" in your
installation) which can be "sourced" from the shell like this:
$ source /opt/denx/eldk4.1/eldk_init 74xx
ARCH=3Dppc
CROSS_COMPILE=3Dppc_74xx-
DEPMOD=3D/opt/denx/eldk4.1/usr/bin/depmod.pl
PATH=3D/opt/denx/eldk4.1/usr/bin:/opt/denx/eldk4.1/bin: ...
$
ELDK 4.2 will use a much cleverer script "eldk-switch" which allows
to select versions and board like this:
-> eldk-switch -r4.1 sequoia
[ sequoia is using PPC440EPx ]
Setup for ppc_4xxFP (using ELDK 4.1)
-> eldk-switch -r4.2 TQM8540
[ TQM8540 is using MPC8540 ]
Setup for ppc_85xx (using ELDK 4.2)
-> eldk-switch -r4.0 MPC860
Setup for ppc_8xx (using ELDK 4.0)
-> eldk-switch MPC7448
Setup for ppc_74xx (using ELDK 4.2)
> One of the things I want to do is look at how the linux make system =
works now (I recall at times I edit the Makefile
> to hardcode these things).
Never edit the Makefile - this is always a Bad Thing (TM) to do.
Make sure to either set the ARCH and CROSS_COMPILE ariables in your
environment (this is IMHO the more convenient way) or pass them on
the make command line.
Best regards,
Wolfgang Denk
--=20
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Wenn Du ein' weise Antwort verlangst, Mu=DFt Du vern=FCnftig fragen.
-- Goethe, Invektiven
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-16 19:36 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <20071016182425.DCBF0BA804F@mail41-fra.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> > + n) Xilinx EMAC and Xilinx TEMAC
> > +
> > + Xilinx Ethernet devices. Uses common properties from
> > other Ethernet
> > + devices with the following constraints:
> > +
> > + Required properties:
> > + - compatible : Must include one of: "xilinx,plb-temac",
> > + "xilinx,plb-emac", "xilinx-opb-emac"
> > + - dma-mode : Must be one of "none", "simple", "sg" (sg
> > == scatter gather)
>
> I think it's going to be a significant headache to remap things like the
> dma-mode from the xilinx configurations to something else, and then
> interpret them correctly in the drivers.
>
> Although it lacks a bit in style, perhaps, I'd greatly prefer having
> something like:
>
> Ethernet_MAC {
> xilinx,C_DMA_PRESENT = <1>;
> ...
> }
>
> (which happens to correspond to "none" above)
Ugh. Can't say I'm thrilled about this....
But in this case is might be a necessity. The IP core is already
parameterized and the best way to describe the device is to use the
existing parameter names.
I want to be careful though. Parameters can change from one version
of an IP core to another. The driver needs to be able to determine
what version of the IP core is used so that the parameters make sense.
I'm also nervous about adding every possible C_ value to the device
node for each xilinx IP-core; that could make the device tree quite
large. (on the other hand; maybe that doesn't matter... It is
probably a bigger deal for microblaze than powerpc too.).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: Grant Likely @ 2007-10-16 19:37 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <13239003.post@talk.nabble.com>
On 10/16/07, aauer1 <aauer1@gmx.at> wrote:
>
> The on-chip memories are disabled. Only the BRAM is enabled. Now, we also use
> the ELDK 4.1 from Denx and the included cross compiler. The result is the
> same... the Kernel stops at "Now booting the kernel". Now, we also have an
> USB JTAG cable. So, we can debug the memory.
> Probably, anyone has another idea.
There are two common reasons for this behaviour:
1. kernel crashes before the console is configured
2. the console is not configured correctly.
In both cases; finding a way to look at __log_buf is the fastest way
to figure out what is going on.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Refactor booting-without-of.txt
From: Grant Likely @ 2007-10-16 19:39 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Olof Johansson, linuxppc-dev, microblaze-uclinux, David Gibson
In-Reply-To: <20071016172509.08B73FE0077@mail38-dub.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> How about just 'device-tree', referring to any source, and then
> of-device-tree and flat-device-tree to document how the device tree is
> constructed.
> The fact that the API is poorly named is something that can always be
> fixed (and perhaps should be earlier rather than later).
It's not so much that it's poorly named; it's just historically named. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: ioctl32: Unknown cmd
From: Arnd Bergmann @ 2007-10-16 19:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Kernel Development, Jens Axboe
In-Reply-To: <Pine.LNX.4.62.0710161642200.20196@pademelon.sonytel.be>
On Tuesday 16 October 2007, Geert Uytterhoeven wrote:
> The recent (post 2.6.23) changes to compat_ioctl made the reporting of
> unsupported ioctls more verbose. E.g. on the PS3 I get:
>
> | ioctl32(cdrom_id:608): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-11-0
> | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
> | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
>
> The first one is triggered by the detection of the CD/DVD/BD-ROM driver,
> The others are triggered by me running hdparm.
>
> Was this intentional?
>
No, it was certainly not intentional, and I can't figure out why it happens.
The ioctl numbers from your example are HDIO_DRIVE_CMD and CDROM_GET_CAPABILITY,
both of which should be handled through compat_blkdev_driver_ioctl by calling
the native ioctl method of the driver, and return -ENOTTY otherwise.
The one point where it is expected to have changed now is when you try
to do these ioctls on something that is not a block device. Are you sure that
the files you tried them on were created correctly?
Arnd <><
^ permalink raw reply
* Re: Describing devices in the device tree
From: Grant Likely @ 2007-10-16 20:06 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0710161136y7d28ccd6w828f16d30f85ce19@mail.gmail.com>
On 10/16/07, Alan Bennett <embedded@akb.net> wrote:
> I'm using a modified ep8248e.dts to describe my hardware and I want to
> enable the use of 3 standard interrupts.
>
> 1. irq5
> 2. timer1
> 3. timer2
>
> How bad does this look?
> soc --> cpm -->
> timer {
> device_type = "timer";
> compatible = "fsl,mpc8248-timer";
> interrupts = <c 8 d 8>;
> interrupt-parent = <&PIC>;
> };
> irq5 {
> device_type = "irq5";
> compatible = "fsl,mpc8248-irq5";
> interrupts = <17 8>;
> interrupt-parent = <&PIC>;
> };
Don't do this. Instead, describe the device that generates the
interrupt. You don't need the device_type property either unless it
is a common device. The compatible property should also describe your
device; not the irq line.
Just creating a device node to describe an irq line doesn't buy you
anything because your device driver still needs to have the knowledge
built into it to use IRQ5. You may as well have just hard coded the
value into your driver instead of traversing through the device tree
to get it.
You get an advantage when you create a node for you *device* that your
device driver can bind, and embed into that node the IRQ line that it
uses.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: T Ziomek @ 2007-10-16 20:12 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40710161237t54688b71g9c7cf9acdac2b744@mail.gmail.com>
On Tue, 16 Oct 2007, Grant Likely wrote:
>
> On 10/16/07, aauer1 <aauer1@gmx.at> wrote:
>>
>> The on-chip memories are disabled. Only the BRAM is enabled. Now, we also use
>> the ELDK 4.1 from Denx and the included cross compiler. The result is the
>> same... the Kernel stops at "Now booting the kernel". Now, we also have an
>> USB JTAG cable. So, we can debug the memory.
>> Probably, anyone has another idea.
>
> There are two common reasons for this behaviour:
> 1. kernel crashes before the console is configured
> 2. the console is not configured correctly.
>
> In both cases; finding a way to look at __log_buf is the fastest way
> to figure out what is going on.
Woah. Grant's [good] advise notwithstanding, I'm confused
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Ack, sorry! [was Re: Linux booting problem on Xilinx ppc]
From: T Ziomek @ 2007-10-16 20:13 UTC (permalink / raw)
To: aauer1, linuxppc-embedded
In-Reply-To: <fa686aa40710161237t54688b71g9c7cf9acdac2b744@mail.gmail.com>
Please ignore my previous msg; I wanted to <cancel> rather than <send>...
Sorry.
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: Grant Likely @ 2007-10-16 20:14 UTC (permalink / raw)
To: T Ziomek; +Cc: aauer1, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0710161511280.22843@gauley.ddna.labs.mot.com>
On 10/16/07, T Ziomek <ctz001@email.mot.com> wrote:
> On Tue, 16 Oct 2007, Grant Likely wrote:
> >
> > There are two common reasons for this behaviour:
> > 1. kernel crashes before the console is configured
> > 2. the console is not configured correctly.
> >
> > In both cases; finding a way to look at __log_buf is the fastest way
> > to figure out what is going on.
>
> Woah. Grant's [good] advise notwithstanding, I'm confused
In what way?
>
> --
> /"\ ASCII Ribbon Campaign |
> \ / | Email to user 'CTZ001'
> X Against HTML | at 'email.mot.com'
> / \ in e-mail & news |
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* New time code miscalculates cpu usage
From: Olof Johansson @ 2007-10-16 20:25 UTC (permalink / raw)
To: paulus, benh; +Cc: linuxppc-dev
Hi,
Not sure when this started happening, but I wanted to report it. I'll
start bisecting in a day or two if noone else has gotten around to
looking at it:
$ echo "int main(void) { while(1); }" > test.c ; gcc test.c
$ time ./a.out & sleep 2 ; killall a.out
real 0m2.008s
user 0m4.014s
sys 0m0.002s
Seen on POWER5 and PA6T, haven't tried anything else yet.
-Olof
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-16 21:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
In-Reply-To: <20071016115318.0fc36af3@freepuppy.rosehill>
> So this is really just like synchronize_irq()? Using msleep is bogus
> because you want to spin, you are only waiting for a softirq on the other
> cpu to finish. If you wait for a whole millisecond and sleep that
> is far longer than the napi routine should take.
>
> You could even optimize it like synchronize_irq() for the non-SMP case.
It's just like synchronize_irq() indeed. I used the mlseep() just like
napi_disable() mostly because I use it in a very similar context, for
disabling my sub-channels on things like link change etc... where I need
to reconfigure parts of the chip.
I prefer sleeping in my case but I agree that if somebody else was going
to use for something else more performance critical, it might be an
issue. On the other hand, spinning will not be nice for my usage
scenario :-)
I agree about the SMP optimisation though again, in my usage pattern,
it's very unimportant (similar code path as napi_disable)
I'll respin later today though.
Cheers,
Ben.
^ permalink raw reply
* Re: [Linux-fbdev-devel] vga16fb doesn't build on powerpc (vgacon_remap_base)
From: Antonino A. Daplas @ 2007-10-16 21:31 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: linuxppc-dev list
In-Reply-To: <20071016191403.GA5962@nineveh.local>
On Tue, 2007-10-16 at 15:14 -0400, Joseph Fannin wrote:
> vga16fb is an available config option on powerpc, but it won't link
> with my .config:
>
> ERROR: "vgacon_remap_base" [drivers/video/vga16fb.ko] undefined!
>
>
> I'm guessing this is because include/asm-powerpc/vga.h declares
> vgacon_remap_base:
>
> extern unsigned long vgacon_remap_base;
>
>
> ...but arch/powerpc/kernel/setup_32.c wraps the definition in an #ifdef:
>
> #ifdef CONFIG_VGA_CONSOLE
Perhaps #if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_FB_VGA16) ?
or
bool VGA_HARDWARE
#if CONFIG_VGA_HARDWARE
unsigned long vgacon_remap_base;
EXPORT_SYMBOL(vgacon_remap_base);
#endif
and for the Kconfig entry of vgacon and vga16fb
select VGA_HARDWARE if PPC32
(or depends on (VGA_HARDWARE && PPC32))
Tony
^ 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