* Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
From: Michal Simek @ 2008-06-26 21:41 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linux-arch, alan, arnd, vapier.adi, matthew, microblaze-uclinux,
linux-kernel, linuxppc-dev, will.newton, hpa, John Linn, drepper,
john.williams
In-Reply-To: <20080626201813.9662411E0051@mail20-wa4.bigfish.com>
Ok. Thanks for information Steve.
Jon: Only for sure the main difference is only in value handling. Am I right?
If yes, it is easy to change.
M
> It's on my list of things to do, but I'm swamped with a few deadlines at
> the moment.
>
> Steve
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org
> [mailto:linuxppc-dev-
>> bounces+stephen.neuendorffer=xilinx.com@ozlabs.org] On Behalf Of
> Michal Simek
>> Sent: Thursday, June 26, 2008 11:57 AM
>> To: Jon Loeliger
>> Cc: linux-arch@vger.kernel.org; alan@lxorguk.ukuu.org.uk;
> arnd@arndb.de; vapier.adi@gmail.com;
>> matthew@wil.cx; microblaze-uclinux@itee.uq.edu.au;
> linux-kernel@vger.kernel.org; drepper@redhat.com;
>> linuxppc-dev@ozlabs.org; will.newton@gmail.com; hpa@zytor.com; John
> Linn; john.williams@petalogix.com
>> Subject: Re: [PATCH 12/60] microblaze_v4: Generic dts file for
> platforms
>> OK. We have to change fdt generator with Steve.
>>
>> Steve: can you look at it?
>>
>> M
>>
>>
>>> monstr@seznam.cz wrote:
>>>> From: Michal Simek <monstr@monstr.eu>
>>>>
>>>>
>>>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>>>> ---
>>>> arch/microblaze/platform/generic/system.dts | 300
>>>> +++++++++++++++++++++++++++
>>>> 1 files changed, 300 insertions(+), 0 deletions(-)
>>>> create mode 100644 arch/microblaze/platform/generic/system.dts
>>>>
>>>> diff --git a/arch/microblaze/platform/generic/system.dts
>>>> b/arch/microblaze/platform/generic/system.dts
>>>> new file mode 100644
>>>> index 0000000..724a037
>>>> --- /dev/null
>>>> +++ b/arch/microblaze/platform/generic/system.dts
>>>> @@ -0,0 +1,300 @@
>>>> +/*
>>>> + * (C) Copyright 2007-2008 Xilinx, Inc.
>>>> + * (C) Copyright 2007-2008 Michal Simek
>>>> + *
>>>> + * Michal SIMEK <monstr@monstr.eu>
>>>> + *
>>>> + * 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.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public
> License
>>>> + * along with this program; if not, write to the Free Software
>>>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>>>> + * MA 02111-1307 USA
>>>> + *
>>>> + * CAUTION: This file is automatically generated by libgen.
>>>> + * Version: Xilinx EDK 9.2.02 EDK_Jm_SP2.3
>>>> + * Generate by FDT v1.00.a
>>>> + */
>>>> +
>>>> +/ {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + compatible = "xlnx,microblaze";
>>>> + model = "testing";
>>>> + DDR_SDRAM_32Mx16: memory@20000000 {
>>>> + device_type = "memory";
>>>> + reg = < 20000000 2000000 >;
>>>> + } ;
>>>> + chosen {
>>>> + bootargs = "console=ttyUL0,115200 loglevel=15";
>>>> + linux,stdout-path = "/plb@0/serial@40100000";
>>>> + } ;
>>>> + cpus {
>>>> + #address-cells = <1>;
>>>> + #cpus = <1>;
>>>> + #size-cells = <0>;
>>>> + microblaze_0: cpu@0 {
>>>> + clock-frequency = <2faf080>;
>>>
>>> This should really be using the /dts-v1/ format now.
>>>
>>> Thanks,
>>> jdl
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>>
>>>
>>>
> ------------------------------------------------------------------------
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG.
>>> Version: 8.0.101 / Virus Database: 270.4.1/1519 - Release Date:
> 25.6.2008 04:13
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.1/1519 - Release Date: 25.6.2008 04:13
^ permalink raw reply
* Re: [PATCH 30/60] microblaze_v4: support for a.out
From: H. Peter Anvin @ 2008-06-26 21:38 UTC (permalink / raw)
To: monstr
Cc: linux-arch, Adrian Bunk, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, John.Linn, linuxppc-dev,
will.newton, john.williams, drepper, alan
In-Reply-To: <48640A88.8070402@seznam.cz>
Michal Simek wrote:
>> Michal Simek wrote:
>>> I expect it but I haven't information about. I'll check it.
>> I'm assuming Microblaze doesn't actually add a.out support, does it?
>
> I think that any support were there but I assume that no one use it.
Most other new architectures don't bother, hence the question.
-hpa
^ permalink raw reply
* Re: [PATCH 30/60] microblaze_v4: support for a.out
From: Michal Simek @ 2008-06-26 21:30 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-arch, Adrian Bunk, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, John.Linn, linuxppc-dev,
will.newton, john.williams, drepper, alan
In-Reply-To: <4863ED98.50608@zytor.com>
> Michal Simek wrote:
>> I expect it but I haven't information about. I'll check it.
>
> I'm assuming Microblaze doesn't actually add a.out support, does it?
>
> -hpa
I think that any support were there but I assume that no one use it.
M
^ permalink raw reply
* Re: [PATCH 08/60] microblaze_v4: exception handling
From: Michal Simek @ 2008-06-26 21:06 UTC (permalink / raw)
To: Ray Lee
Cc: linux-arch, alan, vapier.adi, arnd, matthew, microblaze-uclinux,
linux-kernel, drepper, linuxppc-dev, will.newton, hpa, monstr,
John.Linn, john.williams
In-Reply-To: <2c0942db0806261243g52edd45eo11ded19bb1f24004@mail.gmail.com>
Ray Lee napsal(a):
> On Thu, Jun 26, 2008 at 12:19 PM, Michal Simek <monstr@seznam.cz> wrote:
>>> On Thu, Jun 26, 2008 at 5:29 AM, <monstr@seznam.cz> wrote:
>>>> +ex_sw:
>>>> + /* Get the destination register number into r5 */
>>>> + lbui r5, r0, ex_reg_op;
>>>> + /* Form store_word jump table offset (sw_table + (8 * regnum)) */
>>>> + la r6, r0, sw_table;
>>>> + add r5, r5, r5;
>>>> + add r5, r5, r5;
>>>> + add r5, r5, r5;
>>>> + add r5, r5, r6;
>>>> + bra r5;
>>> Possibly stupid question: This is part of the unaligned store word
>>> exception handler, yes? Shouldn't the above add's be addk's to
>>> preserve the state of the carry register pre/post store?
>> I don't think that addk is important. I have some tests for exception, I want to
>> cover full exception handling.
>
> Okay. It doesn't match your other exception handlers, though, which is
> why I noticed it in the first place (they use addk).
thanks for notice. I'll keep in my mind when I test it.
M
^ permalink raw reply
* RE: Microblaze init port v4
From: Stephen Neuendorffer @ 2008-06-26 20:27 UTC (permalink / raw)
To: Adrian Bunk, Michal Simek
Cc: linux-arch, alan, vapier.adi, arnd, matthew, microblaze-uclinux,
linux-kernel, linuxppc-dev, will.newton, hpa, John Linn, drepper,
john.williams
In-Reply-To: <20080626194301.GD22827@cs181140183.pp.htv.fi>
We're looking at putting a microblaze toolchain on git.xilinx.com, which
will be slightly easier than grabbing all of petalinux, if people just
want to compile test it. =
At the moment, we would very much like to push the microblaze
architecture code to the gcc mainline. I believe the main barrier is
that we don't have someone with the bandwidth to interact with the gcc
community at the moment, although hiring someone to work on it may be in
the works. (Anyone interested?)
Steve
> -----Original Message-----
> From: Adrian Bunk [mailto:bunk@kernel.org]
> Sent: Thursday, June 26, 2008 12:43 PM
> To: Michal Simek
> Cc: linux-kernel@vger.kernel.org; arnd@arndb.de;
linux-arch@vger.kernel.org; Stephen Neuendorffer;
> John Linn; john.williams@petalogix.com; matthew@wil.cx;
will.newton@gmail.com; drepper@redhat.com;
> microblaze-uclinux@itee.uq.edu.au; grant.likely@secretlab.ca;
linuxppc-dev@ozlabs.org;
> vapier.adi@gmail.com; alan@lxorguk.ukuu.org.uk; hpa@zytor.com
> Subject: Re: Microblaze init port v4
> =
> On Thu, Jun 26, 2008 at 08:50:37PM +0200, Michal Simek wrote:
> > Hi Adrian,
> >
> > > On Thu, Jun 26, 2008 at 02:29:29PM +0200, monstr@seznam.cz wrote:
> > >> Hi everybody,
> > >>
> > >> current linux version is 2.6.26-rc8 and I think this is the right
time
> > >> to send latest patches againts rc8 for Microblaze CPU.
> > >> ...
> > >
> > > Thanks for your work on getting the architecture included.
> > >
> > > I have two questions:
> > >
> > > Where can I find a toolchain for compiling a Microblaze kernel?
> > I personally use petalogix toolchain from www.petalogix.com.
> >
> > > What is the status of Microblaze support in upstream binutils and
gcc?
> >
> > I don't have any information about. We will discuss with John
Williams and guys
> > from Xilinx
> > what we can do for it.
> =
> Thanks!
> =
> > M
> =
> cu
> Adrian
> =
> --
> =
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets
From: Scott Wood @ 2008-06-26 20:22 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: John Linn, paulus, linuxppc-dev, petermendham
In-Reply-To: <20080626201643.D01221788058@mail223-wa4.bigfish.com>
Stephen Neuendorffer wrote:
>> cuImage is for boards running an older U-Boot that does not understand
>> device trees.
>
> Forgive my ignorance here, but what specifically does this imply? As
> far as I can tell, generally speaking, some of the board-specific
> information is passed into the boot wrapper, which then stuffs it into
> the device tree.
It implies that the binary is in uImage format, targets older u-boot (as
opposed to some other bootloader entirely, which might be targeted with
a dtbImage -- see adder875, for example), and has a device tree embedded.
>> uImage is for device-tree aware U-Boot versions
>
> And this differs from above because it gets a device tree passed in,
> which uboot has already stuffed correctly.
Yes.
>> dtbImage is used for boards that can take an ELF zImage, but still
> need
>> a dtb provided.
>>
>> simpleImage, not sure here.
>
> So both of these are elfs... but how do they differ? Is it only in how
> the right head.s file gets picked up?
Neither is necessarily an ELF. The only simpleboot target I see is a
flat binary, as are some of the dtbImage targets (adder875, ep88xc,
ep405, etc). simpleboot is more of a platform than an image type; it's
a platform that assumes nothing about the firmware that loaded it, and
gets all information from the embedded device tree.
-Scott
^ permalink raw reply
* RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
From: Stephen Neuendorffer @ 2008-06-26 20:18 UTC (permalink / raw)
To: monstr, Jon Loeliger
Cc: linux-arch, john.williams, arnd, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, linuxppc-dev, will.newton, hpa,
John Linn, drepper, alan
In-Reply-To: <4863E68C.30802@seznam.cz>
It's on my list of things to do, but I'm swamped with a few deadlines at
the moment.
Steve
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of
Michal Simek
> Sent: Thursday, June 26, 2008 11:57 AM
> To: Jon Loeliger
> Cc: linux-arch@vger.kernel.org; alan@lxorguk.ukuu.org.uk;
arnd@arndb.de; vapier.adi@gmail.com;
> matthew@wil.cx; microblaze-uclinux@itee.uq.edu.au;
linux-kernel@vger.kernel.org; drepper@redhat.com;
> linuxppc-dev@ozlabs.org; will.newton@gmail.com; hpa@zytor.com; John
Linn; john.williams@petalogix.com
> Subject: Re: [PATCH 12/60] microblaze_v4: Generic dts file for
platforms
> =
> OK. We have to change fdt generator with Steve.
> =
> Steve: can you look at it?
> =
> M
> =
> =
> > monstr@seznam.cz wrote:
> >> From: Michal Simek <monstr@monstr.eu>
> >>
> >>
> >> Signed-off-by: Michal Simek <monstr@monstr.eu>
> >> ---
> >> arch/microblaze/platform/generic/system.dts | 300
> >> +++++++++++++++++++++++++++
> >> 1 files changed, 300 insertions(+), 0 deletions(-)
> >> create mode 100644 arch/microblaze/platform/generic/system.dts
> >>
> >> diff --git a/arch/microblaze/platform/generic/system.dts
> >> b/arch/microblaze/platform/generic/system.dts
> >> new file mode 100644
> >> index 0000000..724a037
> >> --- /dev/null
> >> +++ b/arch/microblaze/platform/generic/system.dts
> >> @@ -0,0 +1,300 @@
> >> +/*
> >> + * (C) Copyright 2007-2008 Xilinx, Inc.
> >> + * (C) Copyright 2007-2008 Michal Simek
> >> + *
> >> + * Michal SIMEK <monstr@monstr.eu>
> >> + *
> >> + * 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.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public
License
> >> + * along with this program; if not, write to the Free Software
> >> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> >> + * MA 02111-1307 USA
> >> + *
> >> + * CAUTION: This file is automatically generated by libgen.
> >> + * Version: Xilinx EDK 9.2.02 EDK_Jm_SP2.3
> >> + * Generate by FDT v1.00.a
> >> + */
> >> +
> >> +/ {
> >> + #address-cells =3D <1>;
> >> + #size-cells =3D <1>;
> >> + compatible =3D "xlnx,microblaze";
> >> + model =3D "testing";
> >> + DDR_SDRAM_32Mx16: memory@20000000 {
> >> + device_type =3D "memory";
> >> + reg =3D < 20000000 2000000 >;
> >> + } ;
> >> + chosen {
> >> + bootargs =3D "console=3DttyUL0,115200 loglevel=3D15";
> >> + linux,stdout-path =3D "/plb@0/serial@40100000";
> >> + } ;
> >> + cpus {
> >> + #address-cells =3D <1>;
> >> + #cpus =3D <1>;
> >> + #size-cells =3D <0>;
> >> + microblaze_0: cpu@0 {
> >> + clock-frequency =3D <2faf080>;
> >
> >
> > This should really be using the /dts-v1/ format now.
> >
> > Thanks,
> > jdl
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
> >
------------------------------------------------------------------------
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG.
> > Version: 8.0.101 / Virus Database: 270.4.1/1519 - Release Date:
25.6.2008 04:13
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* RE: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets
From: Stephen Neuendorffer @ 2008-06-26 20:16 UTC (permalink / raw)
To: Josh Boyer; +Cc: John Linn, petermendham, linuxppc-dev, paulus
In-Reply-To: <1214507238.7698.3.camel@weaponx>
> -----Original Message-----
> From: Josh Boyer [mailto:jwboyer@gmail.com]
> Sent: Thursday, June 26, 2008 12:07 PM
> To: Stephen Neuendorffer
> Cc: grant.likely@secretlab.ca; John Linn; linuxppc-dev@ozlabs.com;
paulus@samba.org;
> petermendham@computing.dundee.ac.uk
> Subject: RE: [PATCH] powerpc/bootwrapper: Add documentation of boot
wrappertargets
> =
> On Thu, 2008-06-26 at 09:48 -0700, Stephen Neuendorffer wrote:
> > My unanswered questions:
> >
> > 1) Why are there 4 different types of targets that embed a device
tree?
> > I assume they differ in how they are started loaded, but
(unfortunately)
> > the names are meaningless (With the exception of cuImage, which is
only
> > cryptic.. :) If I'm adding support for a new board, which should I
use?
> =
> They are all needed to deal with different firmwares.
Where 'firmware' really means 'method of invoking the kernel'
> treeImage is for OpenBIOS based boards (Ebony, Walnut, some boards
> running PIBS can also use this). This firmware requires a special
> header on the image file.
So it's not an elf? or it is an .elf? maybe it should be
'openBiosImage'?
=
> cuImage is for boards running an older U-Boot that does not understand
> device trees.
Forgive my ignorance here, but what specifically does this imply? As
far as I can tell, generally speaking, some of the board-specific
information is passed into the boot wrapper, which then stuffs it into
the device tree.
> uImage is for device-tree aware U-Boot versions
And this differs from above because it gets a device tree passed in,
which uboot has already stuffed correctly.
> dtbImage is used for boards that can take an ELF zImage, but still
need
> a dtb provided.
> =
> simpleImage, not sure here.
So both of these are elfs... but how do they differ? Is it only in how
the right head.s file gets picked up?
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [RFC/PATCH 0/3] sched: allow arch override of cpu power
From: Breno Leitao @ 2008-06-26 19:49 UTC (permalink / raw)
To: Nathan Lynch
Cc: linuxppc-dev, Ingo Molnar, Paul Mackerras, linux-kernel,
Anton Blanchard
In-Reply-To: <1213835374-10868-1-git-send-email-ntl@pobox.com>
Hi Nathan,
Nathan Lynch wrote:
> There is an "interesting" quality of POWER6 cores, which each have 2
> hardware threads: assuming one thread on the core is idle, the primary
> thread is a little "faster" than the secondary thread. To illustrate:
>
I found this feature interesting and decided to do some tests.
After some tests I found that the example you post really runs fast in
the first CPU, but a more "elaborated" application runs slower on the
first CPU.
Here is a small example:
# taskset 0x1 time -f "%e, %U, %S" ./a.out ; taskset 0x2 time -f "%e,
%U, %S" ./a.out
10.77, 10.72, 0.01
10.53, 10.48, 0.01
# taskset 0x2 time -f "%e, %U, %S" ./a.out ; taskset 0x1 time -f "%e,
%U, %S" ./a.out
10.55, 10.50, 0.01
10.77, 10.72, 0.01
# cat calc.c
#include <stdio.h>
int main(){
int j = 0;
float i = 42;
srand(123);
while (j++ < 100000000){
i = i*i + i;
i = i/2 + random(2);
}
printf("%d\n", i);
return 0;
}
# cat /proc/cpuinfo
processor : 0
cpu : POWER6 (architected), altivec supported
clock : 5000.001000MHz
revision : 3.2 (pvr 003e 0302)
processor : 1
cpu : POWER6 (architected), altivec supported
clock : 5000.001000MHz
revision : 3.2 (pvr 003e 0302)
...
Note that the IRQ are balanced among the 8 CPUs, and the machine is idle.
Do you know why I get this difference? Something wrong with the test?
Thanks
-
Breno Leitao
Linux Technology Center Brazil
Phone: +55-16-8115-3915 (T/L: 839-1293)
leitao@linux.vnet.ibm.com
^ permalink raw reply
* Re: Microblaze init port v4
From: Adrian Bunk @ 2008-06-26 19:43 UTC (permalink / raw)
To: Michal Simek
Cc: linux-arch, alan, vapier.adi, arnd, matthew, microblaze-uclinux,
linux-kernel, drepper, linuxppc-dev, will.newton, hpa, John.Linn,
john.williams
In-Reply-To: <4863E4FD.6040803@seznam.cz>
On Thu, Jun 26, 2008 at 08:50:37PM +0200, Michal Simek wrote:
> Hi Adrian,
>
> > On Thu, Jun 26, 2008 at 02:29:29PM +0200, monstr@seznam.cz wrote:
> >> Hi everybody,
> >>
> >> current linux version is 2.6.26-rc8 and I think this is the right time
> >> to send latest patches againts rc8 for Microblaze CPU.
> >> ...
> >
> > Thanks for your work on getting the architecture included.
> >
> > I have two questions:
> >
> > Where can I find a toolchain for compiling a Microblaze kernel?
> I personally use petalogix toolchain from www.petalogix.com.
>
> > What is the status of Microblaze support in upstream binutils and gcc?
>
> I don't have any information about. We will discuss with John Williams and guys
> from Xilinx
> what we can do for it.
Thanks!
> M
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 08/60] microblaze_v4: exception handling
From: Ray Lee @ 2008-06-26 19:43 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <4863EBD9.1010601@seznam.cz>
On Thu, Jun 26, 2008 at 12:19 PM, Michal Simek <monstr@seznam.cz> wrote:
>> On Thu, Jun 26, 2008 at 5:29 AM, <monstr@seznam.cz> wrote:
>>> +ex_sw:
>>> + /* Get the destination register number into r5 */
>>> + lbui r5, r0, ex_reg_op;
>>> + /* Form store_word jump table offset (sw_table + (8 * regnum)) */
>>> + la r6, r0, sw_table;
>>> + add r5, r5, r5;
>>> + add r5, r5, r5;
>>> + add r5, r5, r5;
>>> + add r5, r5, r6;
>>> + bra r5;
>>
>> Possibly stupid question: This is part of the unaligned store word
>> exception handler, yes? Shouldn't the above add's be addk's to
>> preserve the state of the carry register pre/post store?
>
> I don't think that addk is important. I have some tests for exception, I want to
> cover full exception handling.
Okay. It doesn't match your other exception handlers, though, which is
why I noticed it in the first place (they use addk).
^ permalink raw reply
* Re: [PATCH 02/60] microblaze_v4: Makefiles for Microblaze cpu
From: Adrian Bunk @ 2008-06-26 19:40 UTC (permalink / raw)
To: Michal Simek
Cc: linux-arch, alan, vapier.adi, arnd, matthew, microblaze-uclinux,
linux-kernel, drepper, linuxppc-dev, will.newton, hpa, John.Linn,
john.williams
In-Reply-To: <4863E414.4090303@seznam.cz>
On Thu, Jun 26, 2008 at 08:46:44PM +0200, Michal Simek wrote:
> Adrian Bunk napsal(a):
> > On Thu, Jun 26, 2008 at 02:29:31PM +0200, monstr@seznam.cz wrote:
> >> ...
> >> --- /dev/null
> >> +++ b/arch/microblaze/Makefile
> >> ...
> >> +# Work out HW multipler support. This is icky.
> >> +# 1. Spartan2 has no HW multiplers.
> >> +# 2. MicroBlaze v3.x always uses them, except in Spartan 2
> >> +# 3. All other FPGa/CPU ver combos, we can trust the CONFIG_ settings
> >> +ifeq (,$(findstring spartan2,$(CONFIG_XILINX_MICROBLAZE0_FAMILY)))
> >> + ifeq ($(CPU_MAJOR),3)
> >> + CPUFLAGS-1 += -mno-xl-soft-mul
> >> + else
> >> + # USE_HW_MUL can be 0, 1, or 2, defining a heirarchy of HW Mul support.
> >> + CPUFLAGS-$(subst 1,,$(CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL)) += -mxl-multiply-high
> >> + CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL) += -mno-xl-soft-mul
> >> + endif
> >> +endif
> >> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
> >> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
> >> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP) += -mxl-pattern-compare
> >> +
> >> +CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
> >> +
> >> +# The various CONFIG_XILINX cpu features options are integers 0/1/2...
> >> +# rather than bools y/n
> >> +CFLAGS += $(CPUFLAGS-1)
> >> +CFLAGS += $(CPUFLAGS-2)
> >> ...
> >
> > Why are the options not bools?
> >
> > cu
> > Adrian
>
> because CONFIG_XILINX_... are 0, 1 or 2 not only y, n.
I understood that.
But _why_ are these options not bools?
In most cases the order of gcc flags does not matter, and it is not
obvious for me why the order matters here.
> M
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 30/60] microblaze_v4: support for a.out
From: H. Peter Anvin @ 2008-06-26 19:27 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Adrian Bunk, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, John.Linn, john.williams
In-Reply-To: <4863ECCE.2000407@seznam.cz>
Michal Simek wrote:
> I expect it but I haven't information about. I'll check it.
I'm assuming Microblaze doesn't actually add a.out support, does it?
-hpa
^ permalink raw reply
* Re: [PATCH 07/60] microblaze_v4: Support for semaphores
From: Michal Simek @ 2008-06-26 19:27 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-arch, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, John.Linn, linuxppc-dev,
will.newton, john.williams, hpa, drepper, alan
In-Reply-To: <20080626143652.GD30954@cs181140183.pp.htv.fi>
OK. I'do it.
M
> On Thu, Jun 26, 2008 at 02:29:36PM +0200, monstr@seznam.cz wrote:
>> From: Michal Simek <monstr@monstr.eu>
>>
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>> ---
>> include/asm-microblaze/semaphore.h | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>> create mode 100644 include/asm-microblaze/semaphore.h
>>
>> diff --git a/include/asm-microblaze/semaphore.h b/include/asm-microblaze/semaphore.h
>> new file mode 100644
>> index 0000000..d9b2034
>> --- /dev/null
>> +++ b/include/asm-microblaze/semaphore.h
>> @@ -0,0 +1 @@
>> +#include <linux/semaphore.h>
>
> In -next all asm/semaphore.h headers gained a
> #warning Use linux/semaphore.h, not asm/semaphore.h
> and the number of asm/semaphore.h is approaching zero.
>
> You can simply drop this patch.
>
> cu
> Adrian
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.1/1519 - Release Date: 25.6.2008 04:13
^ permalink raw reply
* Re: [v2] Add support for Analogue & Micro ASP837E board
From: Scott Wood @ 2008-06-26 19:25 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-dev
On Thu, May 08, 2008 at 10:47:00PM +1000, Bryan O'Donoghue wrote:
> Greetings.
>
> Attached is a patchset to support the ASP8347E.
Sorry for the late reply...
> http://www.analogue-micro.com/ASP8347.html. Due to the fact that the board
> shipped with a root filesystem that requires devfs, you have to run a
> different rootfs with all current kernels. I've been using the 8xx root fs
> from the ELDK via NFS, for this.
8xx has a different cache block size (affecting dcbz, etc); I recommend
using a 6xx toolchain. You'll have floating point that way, as well.
> + dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
> + dt_fixup_mac_addresses(bd.bi_enetaddr);
> + dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 16, bd.bi_busfreq);
> +
timebase on 6xx is busfreq / 4, not busfreq / 16.
> + node = finddevice("/soc/cpm/brg");
> + if (node) {
> + printf("BRG clock-frequency <- 0x%x (%dMHz)\r\n",
> + bd.bi_busfreq, MHZ(bd.bi_busfreq));
> + setprop(node, "clock-frequency", &bd.bi_busfreq, 4);
> + }
> +
> +}
This doesn't exist at all on 834x, and is named differently on 832x/836x.
-Scott
^ permalink raw reply
* Re: [PATCH 30/60] microblaze_v4: support for a.out
From: Michal Simek @ 2008-06-26 19:23 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-arch, alan, vapier.adi, arnd, matthew, microblaze-uclinux,
linux-kernel, drepper, linuxppc-dev, will.newton, hpa, monstr,
John.Linn, john.williams
In-Reply-To: <20080626143713.GE30954@cs181140183.pp.htv.fi>
> On Thu, Jun 26, 2008 at 02:29:59PM +0200, monstr@seznam.cz wrote:
>> From: Michal Simek <monstr@monstr.eu>
>>
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>> ---
>> 0 files changed, 0 insertions(+), 0 deletions(-)
>> create mode 100644 include/asm-microblaze/a.out.h
>>
>> diff --git a/include/asm-microblaze/a.out.h b/include/asm-microblaze/a.out.h
>> new file mode 100644
>> index 0000000..e69de29
>
> As of 2.6.26-rc7 you do no longer need this header.
>
> cu
> Adrian
I expect it but I haven't information about. I'll check it.
M
^ permalink raw reply
* Re: [PATCH 08/60] microblaze_v4: exception handling
From: Michal Simek @ 2008-06-26 19:19 UTC (permalink / raw)
To: Ray Lee
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <2c0942db0806260935p51564a7et6517b39e9a6706dc@mail.gmail.com>
> On Thu, Jun 26, 2008 at 5:29 AM, <monstr@seznam.cz> wrote:
>> +ex_sw:
>> + /* Get the destination register number into r5 */
>> + lbui r5, r0, ex_reg_op;
>> + /* Form store_word jump table offset (sw_table + (8 * regnum)) */
>> + la r6, r0, sw_table;
>> + add r5, r5, r5;
>> + add r5, r5, r5;
>> + add r5, r5, r5;
>> + add r5, r5, r6;
>> + bra r5;
>
> Possibly stupid question: This is part of the unaligned store word
> exception handler, yes? Shouldn't the above add's be addk's to
> preserve the state of the carry register pre/post store?
I don't think that addk is important. I have some tests for exception, I want to
cover full exception handling.
M
^ permalink raw reply
* RE: [PATCH] powerpc/bootwrapper: Add documentation of boot wrapper targets
From: Josh Boyer @ 2008-06-26 19:07 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: John Linn, petermendham, linuxppc-dev, paulus
In-Reply-To: <20080626164842.1D3AB1358053@mail15-sin.bigfish.com>
On Thu, 2008-06-26 at 09:48 -0700, Stephen Neuendorffer wrote:
> My unanswered questions:
>
> 1) Why are there 4 different types of targets that embed a device tree?
> I assume they differ in how they are started loaded, but (unfortunately)
> the names are meaningless (With the exception of cuImage, which is only
> cryptic.. :) If I'm adding support for a new board, which should I use?
They are all needed to deal with different firmwares.
treeImage is for OpenBIOS based boards (Ebony, Walnut, some boards
running PIBS can also use this). This firmware requires a special
header on the image file.
cuImage is for boards running an older U-Boot that does not understand
device trees.
uImage is for device-tree aware U-Boot versions
dtbImage is used for boards that can take an ELF zImage, but still need
a dtb provided.
simpleImage, not sure here.
josh
^ permalink raw reply
* Re: [PATCH 58/60] microblaze_v4: sys_microblaze.c
From: Michal Simek @ 2008-06-26 19:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, alan, Michal Simek, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <200806261748.30698.arnd@arndb.de>
>> +
>> +/*
>> + * sys_ipc() is the de-multiplexer for the SysV IPC calls..
>> + *
>> + * This is really horribly ugly.
>> + */
>
> If it's so horribly ugly, don't do it this way ;-)
:-) this is not my part of code. I'll remove it with syscall changes.
>> +int
>> +sys_ipc(uint call, int first, int second, int third, void *ptr, long fifth)
>> +{
>> + int version, ret;
>> +
>> + version = call >> 16; /* hack for backward compatibility */
>> + call &= 0xffff;
>
> Backwards compatibility with what?
I don't know.
John: I suppose this is your comment.
>> +static inline unsigned long
>> +do_mmap2(unsigned long addr, size_t len,
>> + unsigned long prot, unsigned long flags,
>> + unsigned long fd, unsigned long pgoff)
>> +{
>> + struct file *file = NULL;
>> + int ret = -EBADF;
>> +
>> + flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE);
>> + if (!(flags & MAP_ANONYMOUS))
>> + if (!(file = fget(fd))) {
>> + printk(KERN_INFO "no fd in mmap\r\n");
>> + goto out;
>> + }
>> +
>> + down_write(¤t->mm->mmap_sem);
>> + ret = do_mmap_pgoff(file, addr, len, prot, flags, pgoff);
>> + up_write(¤t->mm->mmap_sem);
>> + if (file)
>> + fput(file);
>> +out:
>> + return ret;
>> +}
>> +
>> +unsigned long sys_mmap2(unsigned long addr, size_t len,
>> + unsigned long prot, unsigned long flags,
>> + unsigned long fd, unsigned long pgoff)
>> +{
>> + return do_mmap2(addr, len, prot, flags, fd, pgoff);
>> +}
>> +
>> +unsigned long sys_mmap(unsigned long addr, size_t len,
>> + unsigned long prot, unsigned long flags,
>> + unsigned long fd, off_t offset)
>> +{
>> + int err = -EINVAL;
>> +
>> + if (offset & ~PAGE_MASK) {
>> + printk(KERN_INFO "no pagemask in mmap\r\n");
>> + goto out;
>> + }
>> +
>> + err = do_mmap2(addr, len, prot, flags, fd, offset >> PAGE_SHIFT);
>> +out:
>> + return err;
>> +}
>
> Which mmap is uClibc really using? I suppose you only need mmap2, even for
> compatibility with any binary ever built for microblaze.
I don't know. Microblaze should be compiled with uClibc and glibc. In case you
need mmap2 for uClibc and mmap for glibc it is ok.
M
> Arnd <><
^ permalink raw reply
* Re: Microblaze init port v4
From: Michal Simek @ 2008-06-26 18:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, john.williams, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, John.Linn, linuxppc-dev,
will.newton, hpa, drepper, alan
In-Reply-To: <200806261709.37045.arnd@arndb.de>
Hi Arnd,
> On Thursday 26 June 2008, monstr@seznam.cz wrote:
>> We have there still problem with syscalls and we don't have chance to
>> fix it to stable version, this is not part which I can do yourself.
>> Microblaze will be n + 1 platform which use some old syscalls.
>> I hope you understand.
>
> That still leaves the problem that a lot of your syscalls have bugs
> copied from other platforms. If you need to maintain backwards compatibility
> with your existing binaries, that's fine, but please fix the code you are
> adding.
This is for now. I'll remove when I will have new toolchain.
I saw an email from you about.
M
^ permalink raw reply
* Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
From: Michal Simek @ 2008-06-26 18:57 UTC (permalink / raw)
To: Jon Loeliger
Cc: linux-arch, alan, arnd, vapier.adi, matthew, microblaze-uclinux,
linux-kernel, drepper, linuxppc-dev, will.newton, hpa, John.Linn,
john.williams
In-Reply-To: <4863B096.7020309@freescale.com>
OK. We have to change fdt generator with Steve.
Steve: can you look at it?
M
> monstr@seznam.cz wrote:
>> From: Michal Simek <monstr@monstr.eu>
>>
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>> ---
>> arch/microblaze/platform/generic/system.dts | 300
>> +++++++++++++++++++++++++++
>> 1 files changed, 300 insertions(+), 0 deletions(-)
>> create mode 100644 arch/microblaze/platform/generic/system.dts
>>
>> diff --git a/arch/microblaze/platform/generic/system.dts
>> b/arch/microblaze/platform/generic/system.dts
>> new file mode 100644
>> index 0000000..724a037
>> --- /dev/null
>> +++ b/arch/microblaze/platform/generic/system.dts
>> @@ -0,0 +1,300 @@
>> +/*
>> + * (C) Copyright 2007-2008 Xilinx, Inc.
>> + * (C) Copyright 2007-2008 Michal Simek
>> + *
>> + * Michal SIMEK <monstr@monstr.eu>
>> + *
>> + * 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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>> + * MA 02111-1307 USA
>> + *
>> + * CAUTION: This file is automatically generated by libgen.
>> + * Version: Xilinx EDK 9.2.02 EDK_Jm_SP2.3
>> + * Generate by FDT v1.00.a
>> + */
>> +
>> +/ {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "xlnx,microblaze";
>> + model = "testing";
>> + DDR_SDRAM_32Mx16: memory@20000000 {
>> + device_type = "memory";
>> + reg = < 20000000 2000000 >;
>> + } ;
>> + chosen {
>> + bootargs = "console=ttyUL0,115200 loglevel=15";
>> + linux,stdout-path = "/plb@0/serial@40100000";
>> + } ;
>> + cpus {
>> + #address-cells = <1>;
>> + #cpus = <1>;
>> + #size-cells = <0>;
>> + microblaze_0: cpu@0 {
>> + clock-frequency = <2faf080>;
>
>
> This should really be using the /dts-v1/ format now.
>
> Thanks,
> jdl
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.1/1519 - Release Date: 25.6.2008 04:13
^ permalink raw reply
* Re: Microblaze init port v4
From: Michal Simek @ 2008-06-26 18:50 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-arch, alan, vapier.adi, arnd, matthew, microblaze-uclinux,
linux-kernel, drepper, linuxppc-dev, will.newton, hpa, John.Linn,
john.williams
In-Reply-To: <20080626150121.GB22025@cs181140183.pp.htv.fi>
Hi Adrian,
> On Thu, Jun 26, 2008 at 02:29:29PM +0200, monstr@seznam.cz wrote:
>> Hi everybody,
>>
>> current linux version is 2.6.26-rc8 and I think this is the right time
>> to send latest patches againts rc8 for Microblaze CPU.
>> ...
>
> Thanks for your work on getting the architecture included.
>
> I have two questions:
>
> Where can I find a toolchain for compiling a Microblaze kernel?
I personally use petalogix toolchain from www.petalogix.com.
> What is the status of Microblaze support in upstream binutils and gcc?
I don't have any information about. We will discuss with John Williams and guys
from Xilinx
what we can do for it.
M
>> Best regards,
>> Michal Simek
>
> TIA
> Adrian
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.1/1519 - Release Date: 25.6.2008 04:13
^ permalink raw reply
* Re: [PATCH 02/60] microblaze_v4: Makefiles for Microblaze cpu
From: Michal Simek @ 2008-06-26 18:46 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-arch, alan, vapier.adi, arnd, matthew, microblaze-uclinux,
linux-kernel, drepper, linuxppc-dev, will.newton, hpa, monstr,
John.Linn, john.williams
In-Reply-To: <20080626143623.GC30954@cs181140183.pp.htv.fi>
Adrian Bunk napsal(a):
> On Thu, Jun 26, 2008 at 02:29:31PM +0200, monstr@seznam.cz wrote:
>> ...
>> --- /dev/null
>> +++ b/arch/microblaze/Makefile
>> ...
>> +# Work out HW multipler support. This is icky.
>> +# 1. Spartan2 has no HW multiplers.
>> +# 2. MicroBlaze v3.x always uses them, except in Spartan 2
>> +# 3. All other FPGa/CPU ver combos, we can trust the CONFIG_ settings
>> +ifeq (,$(findstring spartan2,$(CONFIG_XILINX_MICROBLAZE0_FAMILY)))
>> + ifeq ($(CPU_MAJOR),3)
>> + CPUFLAGS-1 += -mno-xl-soft-mul
>> + else
>> + # USE_HW_MUL can be 0, 1, or 2, defining a heirarchy of HW Mul support.
>> + CPUFLAGS-$(subst 1,,$(CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL)) += -mxl-multiply-high
>> + CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL) += -mno-xl-soft-mul
>> + endif
>> +endif
>> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
>> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
>> +CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP) += -mxl-pattern-compare
>> +
>> +CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
>> +
>> +# The various CONFIG_XILINX cpu features options are integers 0/1/2...
>> +# rather than bools y/n
>> +CFLAGS += $(CPUFLAGS-1)
>> +CFLAGS += $(CPUFLAGS-2)
>> ...
>
> Why are the options not bools?
>
> cu
> Adrian
because CONFIG_XILINX_... are 0, 1 or 2 not only y, n.
M
^ permalink raw reply
* Re: [PATCH 46/60] microblaze_v4: termbits.h termios.h
From: Michal Simek @ 2008-06-26 18:44 UTC (permalink / raw)
To: Alan Cox
Cc: linux-arch, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, John.Linn, linuxppc-dev,
will.newton, hpa, drepper, john.williams
In-Reply-To: <20080626141837.0f8f439d@lxorguk.ukuu.org.uk>
OK.I'll fix it.
M
>> +++ b/include/asm-generic/termbits.h
>> @@ -0,0 +1,200 @@
>
>> +/* c_cflag bit meaning */
>> +
>> +#define CBAUD 0010017
>> +#define B0 0000000 /* hang up */
>
> You need BOTHER in here as well - especially if it is going to be generic.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] powerpc: add of_find_next_property andof_get_aliased_index
From: Stefan Roese @ 2008-06-26 18:41 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20080626142732.0ff6e64c@lappy.seanm.ca>
On Thursday 26 June 2008, Sean MacLennan wrote:
> > Well, there's a lot of disagreement on this subject. Not only do we
> > not agree on a method of enumerating devices, a lot of people have a
> > problem with the concept of enumerating them in the first place!
>
> An interesting point is that I enforced an index in the i2c-ibm_iic
> driver with no disagreement at all ;)
You have been lucky I suppose. :)
I could easily just have used this existing "index" property for the other 4xx
boards, but expected NAK's for this. That and because FSL uses "cell-index"
is why I asked prior to sending patches.
Now I have no idea how to support I2C on the other 4xx boards. Perhaps Josh
could advise how this should be done?
Best regards,
Stefan
^ 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