* Re: [PATCH] [POWERPC] powerpc: Add -mno-spe for ARCH=powerpc builds
From: Josh Boyer @ 2007-10-19 11:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <12EA14AC-6A3E-4322-9083-0C18996EC227@kernel.crashing.org>
On Thu, 18 Oct 2007 22:20:49 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 18, 2007, at 6:19 PM, Paul Mackerras wrote:
>
> > Kumar Gala writes:
> >
> >> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> >
> > Your commit message doesn't give any reason why you are doing this, or
> > any explanation of what goes wrong without it. In fact, the commit
> > message is completely empty. :) Please resubmit with a decent commit
> > message.
>
> I will, just as an FYI I based this on your commit for -mno-altivec
> (which has no rationale for the commit) :)
Do as he says, not as he does! ;)
josh
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-19 12:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <18200.3600.459275.823335@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Sergei Shtylyov writes:
>> And now you have incomplete read_persistent_clock() implementation for
> I don't see anything incomplete about it. If you do, feel free to
> post a patch.
The xtime_lock is still grabbed by time_init()
>>example, god knows why it was preferred to mine -- well, it also implemented
> Your most recent post of your patch to implement read_persistent_clock
> was in May -- five months ago -- and you said this about it: "This
Right, the most recent was in May but that was only a recast of the
October version (i.e. year old) -- that patch got somehow dropped from later
the -rt patches IIRC.
> patch hasn't received a good testing though".
Right, it never has been tested on macines with RTC. That was a fair
warning. :-)
> You don't have to be a god to figure out why I preferred a patch that
> had been tested, where the author was responding to comments and
> posting updated versions of his patch in the period leading up to the
> merge window, over that.
Unfortunately, I didn't have time to try pusing it into every -rc1 since
2.6.18 -- there has been experimental hrtimers patchset at that time with even
x86 stuff being unmerged to mainline, so the stuff could only be pushed into
that patchset last autumn. I was going to try addressing vDSO stuff, yet there
has been too much work aside of that. Still, I've answered the mails. :-)
>> I just wanted the reasons clarified and got what I wanted -- as I thought,
>>the decision behind preferring patches was somewhat biased, nobody really
>>cared about code quality or just wasn't familiar with hrtimers enough to judge
>>on the code quality...
> You really know how to persuade people to cooperate, don't you... :P
Well, I'm not persuading anybody, sine I don't believe that I can persuade
somebody to do my work, so had to just vainly complain :-).
However, I agree that my complaints/ comments might have been somewhat
rash and unjust -- Tony's patches are *not* that bad after all. :-)
The only thing I'm still unusre about is that deterministic accounting.
Could you point me at the patch which deals with this (at least for System 390
:-)?
> Paul.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Paul Mackerras @ 2007-10-19 12:24 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <471899D1.2000903@ru.mvista.com>
Sergei Shtylyov writes:
> BTW, why not handle the decrementer difference right in set_dec() where we
> already have #ifdef'ed code?
Excellent idea. Let's do that.
Paul.
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Paul Mackerras @ 2007-10-19 12:36 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <47189EF3.7010103@ru.mvista.com>
Sergei Shtylyov writes:
> The xtime_lock is still grabbed by time_init()
That was left in there because we are setting sys_tz and do_gtod, and
do_gtod at least is only updated with the xtime_lock held. Of course,
at that early stage in the boot process, no lock is really needed, but
xtime_lock was taken for consistency with other code.
In fact there's quite a lot of stuff in there that could be removed
now. I also want to make the vdso use an algorithm more like what
getnstimeofday does.
> The only thing I'm still unusre about is that deterministic accounting.
> Could you point me at the patch which deals with this (at least for System 390
See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look
for posts to lkml by Christian Borntraeger, who has been pursuing the
issue (subject "Re: [stable] 2.6.23 regression: top displaying 9999%
CPU usage").
Paul.
^ permalink raw reply
* Re: [PATCH] [POWERPC] powerpc: Add -mno-spe for ARCH=powerpc builds
From: Jon Loeliger @ 2007-10-19 12:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <12EA14AC-6A3E-4322-9083-0C18996EC227@kernel.crashing.org>
So, like, the other day Kumar Gala mumbled:
>
> On Oct 18, 2007, at 6:19 PM, Paul Mackerras wrote:
>
> > Your commit message doesn't give any reason why you are doing this, or
> > any explanation of what goes wrong without it. In fact, the commit
> > message is completely empty. :) Please resubmit with a decent commit
> > message.
>
> I will, just as an FYI I based this on your commit for -mno-altivec
> (which has no rationale for the commit) :)
Hmmm. And also, let's not forget that the mail Subject: line
does contribute to the git log commit message as well.
Thanks,
jdl
^ permalink raw reply
* [POWERPC v2] powerpc: Add -mno-spe for ARCH=powerpc builds
From: Kumar Gala @ 2007-10-19 13:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <E1IirI4-0004Ch-3P@jdl.com>
Newer GCC's are capable of autovectorization for ISA extensions like
AltiVec and SPE. If we happen to build with one of those compilers we
will get SPE instructions in random kernel code. Today we only allow
basic interger code in the kernel and FP, AltiVec, or SPE in special
explicit locations that have handled the proper saving and restoring of
the register state (since on uniprocessor we lazy context switch the
register state for FP, AltiVec, and SPE).
-mno-spe disables the compiler for automatically generating SPE
instructions without our knowledge.
---
Hopefully this is up to Paul's double standard :)
(as normal, its in my git tree, posted here for review).
arch/powerpc/Makefile | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 4e16534..bd87626 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -107,6 +107,9 @@ endif
# No AltiVec instruction when building kernel
KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
+# No SPE instruction when building kernel
+KBUILD_CFLAGS += $(call cc-option,-mno-spe)
+
# Enable unit-at-a-time mode when possible. It shrinks the
# kernel considerably.
KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH v3 9/9] add MPC837x MDS board default device tree
From: Kumar Gala @ 2007-10-19 13:04 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5BCD@zch01exm26.fsl.freescale.net>
>>>>
>>>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
>>>> b/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> [snip]
>>>> + soc837x@e0000000 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + device_type = "soc";
>>>> + ranges = <0 e0000000 00100000>;
>>>> + reg = <e0000000 00000200>;
>>>> + bus-frequency = <0>;
>>>> +
>>>> + wdt@200 {
>>>> + device_type = "watchdog";
>>>
>>> Drop this device_type.
>>>
>>>> + compatible = "mpc83xx_wdt";
>>>> + reg = <200 100>;
>>>> + };
>>>> +
>>>> + i2c@3000 {
>>>> + device_type = "i2c";
>>>
>>> And this one.
>>
>> I've asked Leo to leave this one as all other fsl boards do
>> this and the code depends on it. There was some discussion
>> about this but I wasn't sure if it was closed or not.
>
> I'm afraid not only i2c but also watchdog and spi need device_type
> now.
> Shall we proceed removing the type check?
We are NOT changing that code until 2.6.25.
- k
^ permalink raw reply
* Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
From: Kumar Gala @ 2007-10-19 13:05 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev list, Tabi Timur-B04825
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5C9B@zch01exm26.fsl.freescale.net>
>>>>>> Export symbols of qe_lib to be used by QE drivers.
>>>>>>
>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>>> ---
>>>>>> arch/powerpc/sysdev/qe_lib/ucc.c | 7 +++++++
>>>>>> arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++++++++
>>>>>> arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++++++++++--
>>>>>> 3 files changed, 25 insertions(+), 2 deletions(-)
>>>>>
>>
>> What happened with this?
>
> This has been merged as commit
> 65482ccf9d00bf4f68e17eb9c656d045d26e5d1f.
Ignore me I see the commit. Timur will just need to EXPORT_SYMBOL()
what additional functions he needs for the uart driver.
- k
^ permalink raw reply
* Re: Building zImage
From: Kumar Gala @ 2007-10-19 13:07 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D7D8D790@corpexc01.corp.networkrobots.com>
On Oct 18, 2007, at 6:22 PM, Siva Prasad wrote:
> Hi,
>
> When I tried to build zImage (make zImage V=1) based on the 2.6.19
> kernel for 8641HPCN board, I got the following error...
>
> make -f scripts/Makefile.build obj=lib
> make -f
> /export/beavis/work/sprasad/2.6.19/linux-2.6.19/scripts/
> Makefile.modpost
> vmlinux
> scripts/mod/modpost -m -o
> /export/beavis/work/sprasad/2.6.19/linux-2.6.19/Module.symvers
> vmlinux
> rm -f .old_version
> make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> arch/powerpc/boot/zImage
> ln: accessing `arch/powerpc/boot/zImage': No such file or directory
> make[1]: *** [arch/powerpc/boot/zImage] Error 1
> make: *** [zImage] Error 2
>
> When I looked into the Makefile, "image-y" was having no value. So,
> "ln"
> was failing. Do I have to select one of the below options of zImage. I
> am not really sure which one to use for 8641 supported by FreeScale.
>
> image-$(CONFIG_PPC_PSERIES) += zImage.pseries
> image-$(CONFIG_PPC_MAPLE) += zImage.pseries
> image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
> image-$(CONFIG_PPC_CHRP) += zImage.chrp
> image-$(CONFIG_PPC_PMAC) += zImage.pmac
> image-$(CONFIG_DEFAULT_UIMAGE) += uImage
>
> Well!... we are not using U-Boot, so uImage is not an option, and that
> builds fine.
>
> Any way, I tried to make uImage, but I am not sure if it is including
> the dts file in the final uImage built, as the wrapper was passed the
> value of platform as "uboot". I am confused.
>
> Thanks for your help in advance.
uImage's do NOT include device trees as part of the image.
- k
^ permalink raw reply
* Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
From: Grant Likely @ 2007-10-19 13:09 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-dev
In-Reply-To: <20071019112916.GE27403@nd47.coderock.org>
On 10/19/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 17/10/07 10:36 -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Only the MPC5200 needs this bug fix. MPC5200B is okay.
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > Sven, Domen;
> >
> > Can you please test this patch?
>
> I found no obvious problems with it on Efika (mpc5200b)
Cool, I'll add it to my list of patches for Paulus to pull
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v6 4/9] add platform support for MPC837x MDS board
From: Kumar Gala @ 2007-10-19 13:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <20071019104318.edfd2ad1.sfr@canb.auug.org.au>
On Oct 18, 2007, at 7:43 PM, Stephen Rothwell wrote:
> On Thu, 18 Oct 2007 23:04:02 +0800 Li Yang <leoli@freescale.com>
> wrote:
>>
>> +++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
>> +static void __init mpc837x_mds_setup_arch(void)
>> +{
>> +#ifdef CONFIG_PCI
>> + struct device_node *np;
>> +#endif
>> +
>> + if (ppc_md.progress)
>> + ppc_md.progress("mpc837x_mds_setup_arch()", 0);
>> +
>> +#ifdef CONFIG_PCI
>> + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
>
> for_each_node_by_type(np, "pci")
>
>> +static int __init mpc837x_mds_probe(void)
>> +{
>> + unsigned long root = of_get_flat_dt_root();
>> +
>> + return of_flat_dt_is_compatible(root, "fsl,mpc837xmds");
>
> To call these two routines, you should include <asm/prom.h> directly.
what's the rule of thumb to know when to include <asm/prom.h> does
everything starting with of_flat_* come from there?
- k
^ permalink raw reply
* Re: [PATCH v5 9/9] add MPC837x MDS board default device tree
From: Kumar Gala @ 2007-10-19 13:10 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Phillips Kim-R1AAHA, paulus, David Gibson
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5C7A@zch01exm26.fsl.freescale.net>
On Oct 19, 2007, at 2:31 AM, Li Yang-r58472 wrote:
>> -----Original Message-----
>> From: David Gibson [mailto:david@gibson.dropbear.id.au]
>> Sent: Friday, October 19, 2007 8:56 AM
>> To: Li Yang-r58472
>> Cc: galak@kernel.crashing.org; paulus@samba.org;
>> linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH v5 9/9] add MPC837x MDS board default device tree
>>
>> On Thu, Oct 18, 2007 at 06:16:20PM +0800, Li Yang wrote:
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> ---
>>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> b/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> new file mode 100644
>>> index 0000000..8530de6
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> @@ -0,0 +1,282 @@
>> [snip]
>>> + crypto@30000 {
>>> + model = "SEC3";
>>> + compatible = "talitos";
>>
>> That compatible doesn't look specific enough. It should at
>> least have a vendor portion. In general it's best to have
>> all the information you need to pick a driver and options in
>> compatible, rather than splitting that info into model.
>
> I think we could do this in a separate patch. Change the spec and
> then
> update all the in-tree device tree with SEC node.
agreed.
- k
^ permalink raw reply
* Re: [PATCH v3 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Kumar Gala @ 2007-10-19 13:23 UTC (permalink / raw)
To: cbou; +Cc: linuxppc-dev
In-Reply-To: <20071018222927.GA1475@zarina>
On Oct 18, 2007, at 5:29 PM, Anton Vorontsov wrote:
> On Thu, Oct 18, 2007 at 02:58:25PM -0500, Kumar Gala wrote:
> [...]
>>> +
>>> + flash@0,0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
>>> + reg = <0 0 2000000>;
>>> + bank-width = <2>;
>>> + device-width = <1>;
>>> +
>>
>> Are you basing the partition map on something or making it up?
>> Clearly hrcw & u-boot are at fixed offsets, wondering about kernel &
>> rootfs?
>
> I'm making it up. From the brief look at the u-boot* git sources,
> there is no `flashboot` yet, thus I'm free to make this up...
>
> I've partitioned this flash based on these thoughts:
>
> 1. HRCW - whole sector, to not wear out it, plus it's impossible to
> create just 64 bytes partition;
this makes sense.
> 2. Kernel - 2MB, should be enough for bootup kernels?
seems reasonable.
> 3. Rootfs - the rest up to...
do we need a small section for the device tree?
> 4. U-Boot at the end.
can we reorder partitions? not sure if there is any value in having
the things we know will always be there like hrcw & u-boot at fixed
mtd0, mtd1, etc.
>
> I'm not saying that it's best map ever, I'm open to suggestions. ;-)
>
> * Unfortunately I didn't look at the stock Freescale u-boot, maybe
> there was flashboot, most probably.. I'll find the CD to look this
> up.
Yeah I have no idea what we ship w/regards to the BSPs.
- k
^ permalink raw reply
* Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
From: Kumar Gala @ 2007-10-19 13:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18199.60025.563689.10810@cargo.ozlabs.ibm.com>
On Oct 18, 2007, at 6:21 PM, Paul Mackerras wrote:
> Yuri Tikhonov writes:
>
>> The following patch adds support for 256KB PAGE_SIZE on ppc44x-
>> based boards.
>> The applications to be run on the kernel with 256KB PAGE_SIZE have
>> to be
>> built using the modified version of binutils, where the MAXPAGESIZE
>> definition is set to 0x40000 (as opposite to standard 0x10000).
>
> Have you measured the performance using a 64kB page size? If so, how
> does it compare with the 256kB page size?
I was wondering about this as well? Isn't this technically in
violation of the ABI?
- k
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-19 13:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <18200.42194.853246.935329@cargo.ozlabs.ibm.com>
Hello.
Paul Mackerras wrote:
>> The xtime_lock is still grabbed by time_init()
Oops, I got distracted and hadn't finish the passage.
My patch got rid of this xtime_lock stuff -- but this was in a different
context, with all vDSO initialization code in between being killed by John's
patch. I'm not sure it still has sense to hold this lock in time_init()
around that initialization...
> That was left in there because we are setting sys_tz
My patch moved that to read_persistent_clock()...
> and do_gtod, and do_gtod at least is only updated with the xtime_lock held.
> Of course, at that early stage in the boot process, no lock is really needed, but
> xtime_lock was taken for consistency with other code.
Thanks for claryfing this.
>> The only thing I'm still unusre about is that deterministic accounting.
>>Could you point me at the patch which deals with this (at least for System 390
> See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look
Wait, how this is related to the hrtimer's event handlers not being able
to call account_process_time() from arch/powerpc/kernel/time.c instead of
update_process_timess()?
> for posts to lkml by Christian Borntraeger, who has been pursuing the
> issue (subject "Re: [stable] 2.6.23 regression: top displaying 9999%
> CPU usage").
Fun. :-)
> Paul.
WBR, Sergei
^ permalink raw reply
* RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
From: Medve Emilian-EMMEDVE1 @ 2007-10-19 13:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071018.173032.48505868.davem@davemloft.net>
Hello David
> It only kills the warning on 32-bit systems, the cast is wrong
> either way.
I'm not aware of the QE being present on any 64-bit PowerPC. However,
porting the entire driver to a 64-bit platform is an exercise in itself
as many other things would need tweaking the QE hardware itself. But
that's an orthogonal issue. For now I just want to fix that warning.
>=20
> > ugeth->tx_bd_ring_offset[j] =3D
> > - kmalloc((u32) (length + align),=20
> GFP_KERNEL);
> > + (u32)kmalloc(length + align,=20
> GFP_KERNEL);
> > =20
> > if (ugeth->tx_bd_ring_offset[j] !=3D 0)
> > ugeth->p_tx_bd_ring[j] =3D
>=20
> Pointers can be up to "unsigned long" in size, therefore that
> is the minimal amount of storage you need to store them into
> if they are needed in integer form for some reason.
>=20
> Any cast from pointer to integer like this is a huge red flag.
Agreed, but again, I'm not trying to fix the entire driver or to port it
to a different architecture.
For the current situation, 32-bit QE, 32-bit PowerPC, do you find the
patch acceptable?
Cheers,
Emil.
^ permalink raw reply
* Re: [PATCH v6 4/9] add platform support for MPC837x MDS board
From: Stephen Rothwell @ 2007-10-19 13:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <044B09E9-2B1B-4BCC-BDFD-31269E41CC8F@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
On Fri, 19 Oct 2007 08:10:00 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> what's the rule of thumb to know when to include <asm/prom.h> does
> everything starting with of_flat_* come from there?
Basically anything that deals with the flattened device tee should
include asm/prom.h. This may change in the future, but that will be my
problem. linux/of.h should be included for dealing with the unflattened
device tree.
--
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
* Linux root file system with X window support for a powerpc board
From: mahendra varman @ 2007-10-19 14:00 UTC (permalink / raw)
To: XFree86
[-- Attachment #1: Type: text/plain, Size: 213 bytes --]
Hi all
Can anybody help me how to create a Linux root file system with X window
support for a powerpc 74xx based board ?
Any documents/links related to that is also welcome
Thanks in advance
R.Mahendravarman
[-- Attachment #2: Type: text/html, Size: 251 bytes --]
^ permalink raw reply
* Re: SystemACE driver problem
From: Grant Likely @ 2007-10-19 14:04 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <13290652.post@talk.nabble.com>
On 10/19/07, aauer1 <aauer1@gmx.at> wrote:
>
> Hello
>
> I'm trying to boot a Linux Kernel 2.6.23-rc2 from Grant Likely (thanks for
> the great work) on a Xilinx ML403 board. I want to use the second partition
> of the Compact Flash Card as root filesystem. But the boot process hangs at
> the initialization of the SystemACE module. A strange effect is that the
> DONE LED (configuration of the FPGA is done) turns off. So, this means that
> the FPGA loses his configuration.
> Has anybody recognized a similar problem with the SystemACE module??
>
> The boot log:
> ========
> [ 0.000000] Linux version 2.6.23-rc2 (bbauer@soclin) (gcc version 4.0.0
> (DEN7
> [ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
> [ 0.000000] Zone PFN ranges:
> [ 0.000000] DMA 0 -> 16384
> [ 0.000000] Normal 16384 -> 16384
> [ 0.000000] Movable zone start PFN for each node
> [ 0.000000] early_node_map[1] active PFN ranges
> [ 0.000000] 0: 0 -> 16384
> [ 0.000000] Built 1 zonelists in Zone order. Total pages: 16256
> [ 0.000000] Kernel command line: console=ttyUL0 root=/dev/xsa2 rw
> [ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
> [ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
> [ 0.000328] Console: colour dummy device 80x25
> [ 0.001390] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> [ 0.002934] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> [ 0.029759] Memory: 63244k available (1176k kernel code, 388k data, 84k
> init)
> [ 0.120774] Mount-cache hash table entries: 512
> [ 0.171986] io scheduler noop registered
> [ 0.172248] io scheduler anticipatory registered (default)
> [ 0.172300] io scheduler deadline registered
> [ 0.172508] io scheduler cfq registered
> [ 0.268807] uartlite.0: ttyUL0 at MMIO 0x40600000 (irq = 2) is a uartlite
> [ 0.270399] console [ttyUL0] enabled
> [ 1.762725] RAMDISK driver initialized: 8 RAM disks of 8192K size 1024
> blocke
> [ 1.852062] Registering Xilinx SystemACE driver, major=254
> [ 1.919734] xsysace xsysace.0: ace_probe(c01638e0)
Yes, I've seen that. It means something went wrong with the setup and
caused the sysace to reload the FPGA. Is the systemace base address
and bus width set correctly?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* FDT bindings for I2C devices
From: Wolfgang Grandegger @ 2007-10-19 14:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
is it forseen to define and configure devices like RTC, temperature
sensors or EEPROM on the I2C bus with the Flat Device Tree? If yes, how
would the DTS entries look like?
Thanks.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v3 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Anton Vorontsov @ 2007-10-19 14:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <E7D255D6-D30B-4457-898D-1FC601F35A4B@kernel.crashing.org>
On Fri, Oct 19, 2007 at 08:23:19AM -0500, Kumar Gala wrote:
>
> On Oct 18, 2007, at 5:29 PM, Anton Vorontsov wrote:
>
>> On Thu, Oct 18, 2007 at 02:58:25PM -0500, Kumar Gala wrote:
>> [...]
>>>> +
>>>> + flash@0,0 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
>>>> + reg = <0 0 2000000>;
>>>> + bank-width = <2>;
>>>> + device-width = <1>;
>>>> +
>>>
>>> Are you basing the partition map on something or making it up?
>>> Clearly hrcw & u-boot are at fixed offsets, wondering about kernel &
>>> rootfs?
>>
>> I'm making it up. From the brief look at the u-boot* git sources,
>> there is no `flashboot` yet, thus I'm free to make this up...
>>
>> I've partitioned this flash based on these thoughts:
>>
>> 1. HRCW - whole sector, to not wear out it, plus it's impossible to
>> create just 64 bytes partition;
>
> this makes sense.
[Unrelated to the patch.
I've tried to erase first (hrcw) sector, everything passes fine, but
`md fe000000` still gives data back. Probably some hardware magic used
to prevent this? ;-)
=> erase fe000000 fe03ffff
.. done
Erased 2 sectors
=> md fe000000
fe000000: 42424242 42424242 05050505 05050505 BBBBBBBB........
fe000010: 00000000 00000000 83838383 83838383 ................
fe000020: a0a0a0a0 a0a0a0a0 60606060 60606060 ........````````
...
=> md fe020000
fe020000: ffffffff ffffffff ffffffff ffffffff ................
...]
>
>> 2. Kernel - 2MB, should be enough for bootup kernels?
>
> seems reasonable.
>
>> 3. Rootfs - the rest up to...
>
> do we need a small section for the device tree?
Yes, apparently. :-)
>> 4. U-Boot at the end.
>
> can we reorder partitions? not sure if there is any value in having the
> things we know will always be there like hrcw & u-boot at fixed mtd0, mtd1,
> etc.
Good idea.
>>
>> I'm not saying that it's best map ever, I'm open to suggestions. ;-)
>>
>> * Unfortunately I didn't look at the stock Freescale u-boot, maybe
>> there was flashboot, most probably.. I'll find the CD to look this
>> up.
>
> Yeah I have no idea what we ship w/regards to the BSPs.
Here it is:
bootcmd=run ramargs;cp.b fff00000 400000 2000;bootm ff800000 ffa00000 400000
I.e.
0xFF800000 - kernel
0xFFA00000 - ramdisk
0xFFF00000 - dtb, one sector
Reworked patch (lbus+flash) follow, using this stock partitions map:
0x00000000-0x00020000 : "hrcw" <- 128 kB
0x01f80000-0x02000000 : "u-boot" <- 512 kB
0x00020000-0x01800000 : "rootfs" <- 24448 kB
0x01800000-0x01a00000 : "kernel" <- 2048 kB
0x01a00000-0x01f00000 : "ramdisk" <- 5120 kB
0x01f00000-0x01f20000 : "dtb" <- 128 kB
0x01f20000-0x01f80000 : "spare" <- 384 kB
I'm not sure about "ramdisk" partition though, maybe concatenate
kernel+ramdisk to use with initramfs kernels instead?
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [PATCH] [POWERPC] MPC8568E-MDS: create localbus node, add flash support
This patch:
- creates localbus node;
- moves bcsr into it;
- creates flash node (1 32MB Spansion x16 CFI) and its partitions;
- adds localbus to the probe path.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 61 +++++++++++++++++++++++++++-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 +
2 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 5439437..8ddeaf8 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -42,9 +42,64 @@
reg = <00000000 10000000>;
};
- bcsr@f8000000 {
- device_type = "board-control";
- reg = <f8000000 8000>;
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8568-localbus";
+ reg = <e0005000 d8>;
+ ranges = <1 0 f8000000 0008000
+ 0 0 fe000000 2000000>;
+
+ bcsr@1,0 {
+ device_type = "board-control";
+ reg = <1 0 8000>;
+ };
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
+ reg = <0 0 2000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ hrcw@0 {
+ label = "hrcw";
+ reg = <0 20000>;
+ read-only;
+ };
+
+ uboot@1f80000 {
+ label = "u-boot";
+ reg = <1f80000 80000>;
+ read-only;
+ };
+
+ rootfs@20000 {
+ label = "rootfs";
+ reg = <20000 17e0000>;
+ };
+
+ kernel@1800000 {
+ label = "kernel";
+ reg = <1800000 200000>;
+ };
+
+ ramdisk@1a00000 {
+ label = "ramdisk";
+ reg = <1a00000 500000>;
+ };
+
+ dtb@1f00000 {
+ label = "dtb";
+ reg = <1f00000 20000>;
+ };
+
+ spare@1f20000 {
+ label = "spare";
+ reg = <1f20000 60000>;
+ };
+ };
};
soc8568@e0000000 {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 61b3eed..45ffca4 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -139,6 +139,7 @@ static struct of_device_id mpc85xx_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "qe", },
+ { .compatible = "fsl,mpc8568-localbus", },
{},
};
--
1.5.0.6
^ permalink raw reply related
* Re: Linux root file system with X window support for a powerpc board
From: Sebastian Siewior @ 2007-10-19 14:29 UTC (permalink / raw)
To: mahendra varman; +Cc: XFree86, linuxppc-embedded
In-Reply-To: <4ac2955e0710190700q41fe7f6bw8956c5b12be1fa7f@mail.gmail.com>
* mahendra varman | 2007-10-19 19:30:37 [+0530]:
>Can anybody help me how to create a Linux root file system with X window
>support for a powerpc 74xx based board ?
>
>Any documents/links related to that is also welcome
If you are familiar with Gentoo based systems I would recommend [1].
>R.Mahendravarman
[1] http://www.gentoo.org/proj/en/base/embedded/cross-development.xml
Sebastian
^ permalink raw reply
* re: Linux root file system with X window support for a powerpc board
From: Alan Bennett @ 2007-10-19 14:29 UTC (permalink / raw)
To: mahendravarman15, linuxppc-dev
debian:
(on x86/fedora development system) (used on 82xx)
1. debootstrap with the --foreign
i.e. debootstrap --arch powerpc etch http://mirrors.kernel.org/debian
mannually create an inittab, create/copy some default /dev entries
2. boot 74xx target with above root filesystem, run
/debootstrap/debootstrap --second-stage
Now add in packages using apt-get (or add them initially in step 1)
-Alan
Hi all
Can anybody help me how to create a Linux root file system with X
window support for a powerpc 74xx based board ?
Any documents/links related to that is also welcome
Thanks in advance
R.Mahendravarman
^ permalink raw reply
* Re: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
From: Timur Tabi @ 2007-10-19 14:35 UTC (permalink / raw)
To: Emil Medve; +Cc: netdev, leoli, jgarzik, linuxppc-dev
In-Reply-To: <1192745713-20829-1-git-send-email-Emilian.Medve@Freescale.com>
Emil Medve wrote:
> drivers/net/ucc_geth.c: In function 'ucc_geth_startup':
> drivers/net/ucc_geth.c:2614: warning: assignment makes integer from pointer without a cast
> drivers/net/ucc_geth.c:2651: warning: assignment makes integer from pointer without a cast
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Acked-by: Timur Tabi <timur@freescale.com>
^ permalink raw reply
* Re: FDT bindings for I2C devices
From: Grant Likely @ 2007-10-19 14:38 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-embedded
In-Reply-To: <4718BB40.2050901@grandegger.com>
On 10/19/07, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Hello,
>
> is it forseen to define and configure devices like RTC, temperature
> sensors or EEPROM on the I2C bus with the Flat Device Tree? If yes, how
> would the DTS entries look like?
booting-without-of.txt has some information about describing the controller.
Scott Wood made an attempt at defining a device binding for I2C
devices, but it has not been merged into booting-without-of.txt yet.
I've copied what he wrote below. I would add to his definition the
following:
- If compatible is missing, driver should *not* fall back to the device name.
- 'compatible' list should include the exact device in the form "<mfg>,<part>"
Cheers,
g.
Here's the thread and an excerpt from Scott's original post:
http://patchwork.ozlabs.org/linuxppc/patch?id=11223
+ e2) I2C Devices
+
+ Required properties :
+
+ - reg : Unshifted 7-bit I2C address for the device
+
+ Recommended properties :
+
+ - compatible : The name of the Linux device driver that
+ handles this device. If unspecified, the name of the
+ node will be used.
+ - interrupts : <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt. This should be encoded based on
+ the information in section 2) depending on the type of interrupt
+ controller you have.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+
+ Example :
+
+ rtc@68 {
+ device_type = "rtc";
+ compatible = "ds1374";
+ reg = <68>;
+ interrupts = <13 8>;
+ interrupt-parent = <700>;
+ };
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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