* RE: Howto Cross Compile GCC to run on PPC Platform
From: Steven Blakeslee @ 2005-10-28 15:57 UTC (permalink / raw)
To: Jeff Stevens, linuxppc-embedded
> get it to cross compile gcc (to run on ppc). Does anyone=20
> know of a good HowTo to do this?
Karim Yaghmour's "Building Embedded Linux Systems"
=20
> I'm currently downloading the source distro of ELDK, so if=20
> it's already in there I'll find it, but if there is one=20
> elsewhere online please let me know.
Very good, full of features.
^ permalink raw reply
* Re: How the linux use BAT
From: Noah yan @ 2005-10-28 15:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1130452630.29054.77.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]
Thans Ben very much. More questions below ... :)
On 10/27/05, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Thu, 2005-10-27 at 08:05 -0500, Noah yan wrote:
> > I am studying source code for power mac. I am curious how linux use
> > the BAT MMU.
> > The address translation of BAT MMU is parallel with that of
> > segment/page MMU. BAT MMU is known as superpages in other
> > architecture.
> > I am not good at the kernel coding part, hope that my questions share
> > the common fundermental with you and no stupid.
> >
> > Here is my questions:
> > Is the kernel turn BAT MMU on? if so, a BAT array have been setup for
> > that, which part of the kernel code does this?
> > If BAT MMU is used, how about segment/page address translation in
> > kernel, is this also enabled and page table is setup?
> >
> > If both BAT and seg/page are enabled, how the kernel make sure that
> > the correct one is used in adress translation?
>
> Both are used and they don't overlap (well, they can overlap but if they
> do, the BAT takes over).
>
> > Is kernel really use the segment MMU of the powerpc, I have an
> > impression that most kernel only use the page MMU?
>
> page MMU vs. segment MMU ? hrm... what do you mean ? :) There is one MMU
> in the "classsic" PowerPC and it does segment and hash table, you have to
> use both, you can't just use one or the other :) You virtual addresses
> go through the segments first to get the vsid which is then used along
> with the remaining bits of the address to hash into the hash table in
> order to get to the translations.
I am sorry that I did make it clear. It is a little confusing for me between
the hardware segment and the term "segment" or "section" used in a process's
address space (AS). One of my understanding is that a section in a process's
AS is mapped to a hardware segment, which sound straightforward but maybe
wrong because a process binary may have lots of segments that are not the
same size. Pure segment VM is also hard to maintain memory efficiency. Or,
several sections, such as different data section are in segments. I remember
in Linux x86 (posibbly 2.4), segment is not fully used in term of VM. The
segmentation of the kernel and userland are defined upon booting and never
changed later on.
Thanks very much!
Noah
The way linux uses BATs is for the kernel linear mapping. Linux uses by
> default (though that can be configued differently) a 3G/1G split, that
> is the low 3G of address space are used by userland (and covered by the
> user page tables) and the high 1G are used by the kernel. That kernel
> space itself is split into a bottom part up to 768Mb (by default, that
> can also be configured differently) which is the linear mapping, that is
> a single linear mapping of all RAM from 0xc0000000. The rest of the
> kernel space is mapped with page tables and known as the kernel virtual
> space, used for vmalloc and ioremap.
>
> The BATs are used for the linear mapping. They "override" the page
> tables over it if any (though we usually don't bother setting up PTEs
> over the space that is BAT mapped). They basically improve performances
> by not requiring to go through the hash trasnslation for most kernel
> accesses to memory and not using space in the TLB/ERAT.
>
> Ben.
>
>
>
[-- Attachment #2: Type: text/html, Size: 3963 bytes --]
^ permalink raw reply
* Howto Cross Compile GCC to run on PPC Platform
From: Jeff Stevens @ 2005-10-28 15:55 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to compile GCC on an x86 platform to
run natively on an embedded PPC platform. I am able
to compile gcc as a cross compiler (to run on x86),
but can't seem to get it to cross compile gcc (to run
on ppc). Does anyone know of a good HowTo to do this?
I'm currently downloading the source distro of ELDK,
so if it's already in there I'll find it, but if there
is one elsewhere online please let me know.
Thanks,
Jeff Stevens
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: Makefile check for older binutils broken?
From: Marcelo Tosatti @ 2005-10-28 8:52 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20051026220205.GH26475@smtp.west.cox.net>
On Wed, Oct 26, 2005 at 03:02:05PM -0700, Tom Rini wrote:
> On Wed, Oct 26, 2005 at 11:36:48AM -0200, Marcelo Tosatti wrote:
> >
> > Hi,
> >
> > While trying to compile 2.6.14-rc4 on my Pegasos (running Debian unstable):
> >
> > make[2]: Entering directory `/home/marcelo/8xx/linux-2.6.14-rc4'
> > *** 2.6 kernels no longer build correctly with old versions of binutils.
> > *** Please upgrade your binutils to 2.12.1 or newer
> > make[2]: *** [checkbin] Error 1
>
> What's your CONFIG_SHELL set to?
bash
>
> [snip]
> > marcelo@pegasos:~$ /bin/echo dssall | as -many -o /tmp/output.as >/dev/null 2>&1
> > marcelo@pegasos:~$ echo $?
>
> What about if you run the whole test on shell (if ...), does it work there?
> What shell are you running?
Yep, that does the trick. Is it good now?
--- arch/ppc/Makefile.orig 2005-10-26 13:04:43.000000000 -0500
+++ arch/ppc/Makefile 2005-10-28 08:43:22.153202928 -0500
@@ -132,12 +132,12 @@
false; \
fi ; \
fi
- @if ! [[ "/bin/echo dssall | $(AS) -many -o $(TOUT) >/dev/null 2>&1" ]]; then \
+ @(if ! /bin/echo dssall | $(AS) -many -o $(TOUT) >/dev/null 2>&1 ; then\
echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build ' ; \
echo 'correctly with old versions of binutils.' ; \
echo '*** Please upgrade your binutils to 2.12.1 or newer' ; \
false ; \
- fi
+ fi)
CLEAN_FILES += $(TOUT)
^ permalink raw reply
* Patches for 2.6.15
From: Paul Mackerras @ 2005-10-28 13:05 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
If anyone has patches for arch/ppc{,64} and include/asm-ppc{,64} that
they would like to see go upstream now that 2.6.14 is out, other than
patches that are already in the powerpc-merge tree, please let me
know. I am planning to ask Linus to pull the powerpc-merge tree
shortly, and that will probably break your patches.
I think the merge tree is looking pretty good, although the merge is
by no means complete yet. The powermac, pseries and iseries platforms
seem to be working fine with ARCH=powerpc. 32-bit chrp is mostly
there but needs a bit more work.
If possible, I'd like to get to the point where we can remove
arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.
Paul.
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: David Jander @ 2005-10-28 10:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200510281136.21575.roger.larsson@norran.net>
On Friday 28 October 2005 11:36, Roger Larsson wrote:
> >[...]
> > Result: The test takes 3 seconds on kernel-2.6 and 1.5 seconds on
> > kernel-2.4. Here is what "time" has to say about it:
> >
> > real 0m3.119s
> > user 0m3.080s
> > sys 0m0.040s
> >
> > The test loop is pretty brain-dead, but that doesn't matter right now.
> > This is it:
> > [....]
> > gettimeofday(&tv0,NULL);
> > for(t=0L; t<10000000L; t++)
> > {
> > a+=b; /* Do something */
> > }
> > gettimeofday(&tv,NULL);
> > [...]
> >
> > Any ideas?
> > Am I misconfiguring something? Is 2.6 support for mpc8xx still broken
> > (cache/tlb, mm, etc) or is 2.6 supposed to perform THAT bad??
>
> Have you verified the system measured time with wall clock (wrist watch)?
> System time could be wrong on one of the systems.
Yes. Wall-clock==gettimeofday-clock on both systems.
> What is 'a' and 'b'? The only other explanation I can see is that your
> "Do something" is more memory heavy than you think - array calculations?
> (Cache problems should probably give a worse result, but you could check
> that those config registers are the same).
They are just integers with fixed start values. These are in the loop, so it's
not an empty loop and hopefully the compiler won't out-optimize it so easily
(that is of course without specifying any optimization flags). Please don't
tell me it's a lousy benchmark, because I already know that! Be it as lousy
as it is, I shouldn't get _those_ results IMHO.
I have downloaded nbench (hopefully a more serious benchmark for raw computing
power), and the results are as follows (I deliberately excluded tests that
don't make sense (ie. use FP)):
Kernel 2.4.25:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 30.438 : 0.78 : 0.26
STRING SORT : 1.5842 : 0.71 : 0.11
BITFIELD : 7.9506e+06 : 1.36 : 0.28
FP EMULATION : 3.258 : 1.56 : 0.36
IDEA : 108.89 : 1.67 : 0.49
Kernel 2.6.14-r5:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 21.042 : 0.54 : 0.18
STRING SORT : 0.88215 : 0.39 : 0.06
BITFIELD : 6.0979e+06 : 1.05 : 0.22
FP EMULATION : 1.6453 : 0.79 : 0.18
IDEA : 110.25 : 1.69 : 0.50
Now, the strange thing is, IDEA is the only test where 2.6 is slightly faster
(results are consistent over repeated runs). Compiler options are: "-s
-static -Wall -O3 -msoft-float", FP-emulation in the kernel is never
activated.
I think I will need to look closer at how the "IDEA"-test works, but first
I'll have to run the nbench sources through "indent", because they are pretty
unreadable as is ;-)
I also downloaded oprofile, and am studying its manual right now. Hopefully
using this might get me a clue. If anybody already happens to know the
answer, please shout!
Greetings,
--
David Jander
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: Roger Larsson @ 2005-10-28 9:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200510280857.44625.david.jander@protonic.nl>
On Friday 28 October 2005 08.57, David Jander wrote:
> Hi all,
>
> Many people have said it before: 2.6 has a performance penalty specially
> for embdedded systems.
> But now that I have 2.6 running on our 100MHz MPC852T based board, I was
> shocked to see the result:
> The most simple task doing nothing but a closed loop of integer math runs
> at _half_ the speed compared to kernel 2.4.25!!!!!
>
> Here are the conditions for the test:
> - Bogomips are the same, so the CPU definitely runs at the same clock-rate
> (and not half) as with "2.4".
> - Enabling and disabling preemption doesn't have any impact (as expected
> for such kinds of tasks).
> - Setting HZ to 100 or 1000 also has only about 3% impact on speed.
> - The binary of the test program is the same in both cases (no re-compile
> with other optimizations by accident).
> - The hardware is the same (exact same board).
> - Certain hardware drivers that are not ported to "2.6" yet were present in
> "2.4" but (obviously) not in "2.6", but non of them could have a _positive_
> impact on performance.
> - Kernel versions are 2.4.25 (denx-devel) and 2.6.14-rc5 (denx-git
> 20051027).
>
> Result: The test takes 3 seconds on kernel-2.6 and 1.5 seconds on
> kernel-2.4. Here is what "time" has to say about it:
>
> real 0m3.119s
> user 0m3.080s
> sys 0m0.040s
>
> The test loop is pretty brain-dead, but that doesn't matter right now.
> This is it:
> [....]
> gettimeofday(&tv0,NULL);
> for(t=0L; t<10000000L; t++)
> {
> a+=b; /* Do something */
> }
> gettimeofday(&tv,NULL);
> [...]
>
> Any ideas?
> Am I misconfiguring something? Is 2.6 support for mpc8xx still broken
> (cache/tlb, mm, etc) or is 2.6 supposed to perform THAT bad??
Have you verified the system measured time with wall clock (wrist watch)?
System time could be wrong on one of the systems.
What is 'a' and 'b'? The only other explanation I can see is that your
"Do something" is more memory heavy than you think - array calculations?
(Cache problems should probably give a worse result, but you could check that
those config registers are the same).
/RogerL
^ permalink raw reply
* Re: NFS can not mount (linuxppc2.2.4 mpc5200 lxt971)
From: Esben Nielsen @ 2005-10-28 7:49 UTC (permalink / raw)
To: ÏÄÓê; +Cc: linuxppc-embedded
In-Reply-To: <200510281054.AA34079032@NARI-RELAYS.COM>
On Fri, 28 Oct 2005, =CF=C4=D3=EA wrote:
> I have ported linuxppc2.2.4 to my board based on ICECUBE.
> One board can not mount NFS(eth0 =3D lxt971), Message as follow:
>=20
> eth0: config: auto-negotiation on, 100HDX, 10HDX.
> IP-Config: Complete:
> device=3Deth0, addr=3D198.87.102.211, mask=3D255.255.255.0, gw=3D19=
8.87.102.140,
> host=3Doops, domain=3D, nis-domain=3D(none),
> bootserver=3D198.87.102.140, rootserver=3D198.98.102.140, rootpath=
=3D
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Looking up port of RPC 100003/2 on 198.98.102.140
> eth0: status: link up, Unknown speed/duplex, auto-negotiation complete, r=
emote f
> ault.
> portmap: server 198.98.102.140 not responding, timed out
> Root-NFS: Unable to get nfsd port number from server, using default
> Looking up port of RPC 100005/1 on 198.98.102.140
> portmap: server 198.98.102.140 not responding, timed out
> Root-NFS: Unable to get mountd port number from server, using default
> mount: server 198.98.102.140 not responding, timed out
> Root-NFS: Server returned error -5 while mounting /opt/eldk/ppc_82xx
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "nfs" or 02:00
> Please append a correct "root=3D" boot option
> Kernel panic: VFS: Unable to mount root fs on 02:00
>=20
> But i can ping the board from my PC:
>=20
> Pinging 198.87.102.211 with 32 bytes of data:
>=20
> Reply from 198.87.102.211: bytes=3D32 time<10ms TTL=3D64
> Reply from 198.87.102.211: bytes=3D32 time<10ms TTL=3D64
> Reply from 198.87.102.211: bytes=3D32 time<10ms TTL=3D64
> Reply from 198.87.102.211: bytes=3D32 time<10ms TTL=3D64
>=20
>=20
> The other boards using the same program can mount NFS on the same server.
>=20
> What part of this board might be wrong?=20
>=20
I can't tell you what is wrong, but I have seen the same error:
It works fine on the Lite5200 proto board but not on our custom board :-(
Esben
> Thanks!
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* SMP Design
From: Suresh Chandra Mannava @ 2005-10-28 7:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am working on a symmetric multiprocessing(SMP) based board design.
Now, I am into feasibility analysis.
Here are my queries
What qualifies a CPU to be capable of SMP?
Hardware cache coherency
test-and-set, compare-and-swap or load-link/ store-conditional
instructions.
Unique Id(read this in Intel MP specs) Is it required for
powerpc-smp?
CPU-local interrupt controller (intel specific) Is it required
for powerpc-smp
OpenPIC, interrupt routing
what are the other points that support SMP for a CPU. I read that ppc
603 won't support pure SMP.
I am searching for the "considerations for SMP design using powerpc
processors"
please provide pointers for the same.
Can I find any reference design for SMP boards? I am interested
architecture part, interrupt routing and OpenPIC stuff.
I find it hard to find information on SMP board design.
Waiting for your response.
Thanks and Regards,
Suresh Chandra Mannava.
^ permalink raw reply
* Kernel 2.6 on MPC8xx performance trouble...
From: David Jander @ 2005-10-28 6:57 UTC (permalink / raw)
To: linux-ppc-embedded
Hi all,
Many people have said it before: 2.6 has a performance penalty specially for
embdedded systems.
But now that I have 2.6 running on our 100MHz MPC852T based board, I was
shocked to see the result:
The most simple task doing nothing but a closed loop of integer math runs at
_half_ the speed compared to kernel 2.4.25!!!!!
Here are the conditions for the test:
- Bogomips are the same, so the CPU definitely runs at the same clock-rate
(and not half) as with "2.4".
- Enabling and disabling preemption doesn't have any impact (as expected for
such kinds of tasks).
- Setting HZ to 100 or 1000 also has only about 3% impact on speed.
- The binary of the test program is the same in both cases (no re-compile with
other optimizations by accident).
- The hardware is the same (exact same board).
- Certain hardware drivers that are not ported to "2.6" yet were present in
"2.4" but (obviously) not in "2.6", but non of them could have a _positive_
impact on performance.
- Kernel versions are 2.4.25 (denx-devel) and 2.6.14-rc5 (denx-git 20051027).
Result: The test takes 3 seconds on kernel-2.6 and 1.5 seconds on kernel-2.4.
Here is what "time" has to say about it:
real 0m3.119s
user 0m3.080s
sys 0m0.040s
The test loop is pretty brain-dead, but that doesn't matter right now.
This is it:
[....]
gettimeofday(&tv0,NULL);
for(t=0L; t<10000000L; t++)
{
a+=b; /* Do something */
}
gettimeofday(&tv,NULL);
[...]
Any ideas?
Am I misconfiguring something? Is 2.6 support for mpc8xx still broken
(cache/tlb, mm, etc) or is 2.6 supposed to perform THAT bad??
Greetings,
--
David Jander
^ permalink raw reply
* NFS can not mount (linuxppc2.2.4 mpc5200 lxt971)
From: ÏÄÓê @ 2005-10-28 2:54 UTC (permalink / raw)
To: linuxppc-embedded
I have ported linuxppc2.2.4 to my board based on ICECUBE.
One board can not mount NFS(eth0 = lxt971), Message as follow:
eth0: config: auto-negotiation on, 100HDX, 10HDX.
IP-Config: Complete:
device=eth0, addr=198.87.102.211, mask=255.255.255.0, gw=198.87.102.140,
host=oops, domain=, nis-domain=(none),
bootserver=198.87.102.140, rootserver=198.98.102.140, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 198.98.102.140
eth0: status: link up, Unknown speed/duplex, auto-negotiation complete, remote f
ault.
portmap: server 198.98.102.140 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 198.98.102.140
portmap: server 198.98.102.140 not responding, timed out
Root-NFS: Unable to get mountd port number from server, using default
mount: server 198.98.102.140 not responding, timed out
Root-NFS: Server returned error -5 while mounting /opt/eldk/ppc_82xx
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
But i can ping the board from my PC:
Pinging 198.87.102.211 with 32 bytes of data:
Reply from 198.87.102.211: bytes=32 time<10ms TTL=64
Reply from 198.87.102.211: bytes=32 time<10ms TTL=64
Reply from 198.87.102.211: bytes=32 time<10ms TTL=64
Reply from 198.87.102.211: bytes=32 time<10ms TTL=64
The other boards using the same program can mount NFS on the same server.
What part of this board might be wrong?
Thanks!
^ permalink raw reply
* Re: How the linux use BAT
From: Benjamin Herrenschmidt @ 2005-10-27 22:37 UTC (permalink / raw)
To: Noah yan; +Cc: linuxppc-dev
In-Reply-To: <59521b110510270605k6e098826w2d37c50e82ddd758@mail.gmail.com>
On Thu, 2005-10-27 at 08:05 -0500, Noah yan wrote:
> I am studying source code for power mac. I am curious how linux use
> the BAT MMU.
> The address translation of BAT MMU is parallel with that of
> segment/page MMU. BAT MMU is known as superpages in other
> architecture.
> I am not good at the kernel coding part, hope that my questions share
> the common fundermental with you and no stupid.
>
> Here is my questions:
> Is the kernel turn BAT MMU on? if so, a BAT array have been setup for
> that, which part of the kernel code does this?
> If BAT MMU is used, how about segment/page address translation in
> kernel, is this also enabled and page table is setup?
>
> If both BAT and seg/page are enabled, how the kernel make sure that
> the correct one is used in adress translation?
Both are used and they don't overlap (well, they can overlap but if they
do, the BAT takes over).
> Is kernel really use the segment MMU of the powerpc, I have an
> impression that most kernel only use the page MMU?
page MMU vs. segment MMU ? hrm... what do you mean ? :) There is one MMU
in the "classsic" PowerPC and it does segment and hash table, you have to
use both, you can't just use one or the other :) You virtual addresses
go through the segments first to get the vsid which is then used along
with the remaining bits of the address to hash into the hash table in
order to get to the translations.
The way linux uses BATs is for the kernel linear mapping. Linux uses by
default (though that can be configued differently) a 3G/1G split, that
is the low 3G of address space are used by userland (and covered by the
user page tables) and the high 1G are used by the kernel. That kernel
space itself is split into a bottom part up to 768Mb (by default, that
can also be configured differently) which is the linear mapping, that is
a single linear mapping of all RAM from 0xc0000000. The rest of the
kernel space is mapped with page tables and known as the kernel virtual
space, used for vmalloc and ioremap.
The BATs are used for the linear mapping. They "override" the page
tables over it if any (though we usually don't bother setting up PTEs
over the space that is BAT mapped). They basically improve performances
by not requiring to go through the hash trasnslation for most kernel
accesses to memory and not using space in the TLB/ERAT.
Ben.
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Nicolas DET @ 2005-10-27 21:14 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Sven Luther, linuxppc-dev
In-Reply-To: <20051027192655.GA13945@lst.de>
Le jeudi 27 octobre 2005 à 21:26 +0200, Christoph Hellwig a écrit :
> > I don't think this is really dependent on PPC_MULTIPLATFORM,
> > and the driver also supports 64460.
>
> This is not a PCI driver so adding a device table is wrong.
>
I think we all agree ;-).
The point is to have a 'quick' way to get this module automagicly loaded
until we get a proper super duper OFW devices hotplug or whatsoeever
support.
Regards
^ permalink raw reply
* Re: MPC8xx support in 2.6 and [PATCH] USB host controller selection...
From: Wolfgang Denk @ 2005-10-27 21:08 UTC (permalink / raw)
To: jeff; +Cc: David Jander, linux-ppc-embedded
In-Reply-To: <1130423323.8477.24.camel@nighteyes.site>
In message <1130423323.8477.24.camel@nighteyes.site> you wrote:
>
> > > I just rsynced DENX's git tree (cg-clone will crash on a 404 error).
> >
> > Make sure to use current versions of git resp. cogito.
>
> I get the same errors using using the latest versions: git version
> 0.99.8f and cogito-0.15. FWIW, the u-boot.git came down just fine.
...
> Cannot obtain needed blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c
> while processing commit cb7f6ec5c2d64db78984188461dc29b72e924180.
> cg-fetch: objects fetch failed
> cg-clone: fetch failed
Don't know what that means. Accessing the tree using rsync://...
works fine.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
An expert is a person who avoids the small errors while sweeping on
to the grand fallacy.
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Mark A. Greer @ 2005-10-27 20:47 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-embedded
In-Reply-To: <20051027203017.GA13787@localhost.localdomain>
All,
For the record, Sven, Matt Porter, and I talked about this some more on
IRC. I think we agreed that the best solution would be to register a
pci quirk for the bad regs and no longer hide the bridge.
Anyone think that's a bad idea?
Mark
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Sven Luther @ 2005-10-27 20:38 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051027201105.GD13847@mag.az.mvista.com>
On Thu, Oct 27, 2005 at 01:11:05PM -0700, Mark A. Greer wrote:
> Actually, I guess this is more to hide the bridge from the pci_auto when
> it walks the pci buses. If the pci resources are already allocated
> correctly (as in pegasos?) it may not confuse the generic pci code.
> Even if it doesn't get confused, its by luck. The bridge's pci regs
> are NOT pci compliant and, IMHO, its iffy to assume that things woun't
> get messed up.
As said, the pci access rtas functions will stop any access to the non-pci
compliant regs.
Friendly,
Sven Luther
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Sven Luther @ 2005-10-27 20:30 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051027200447.GC13847@mag.az.mvista.com>
On Thu, Oct 27, 2005 at 01:04:47PM -0700, Mark A. Greer wrote:
> On Thu, Oct 27, 2005 at 08:49:21PM +0200, Sven Luther wrote:
> > On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote:
> > > On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> > > > Hi,
> > > >
> > > > I've added platform support for a board based on MPC7447A and MV64462
> > > > Marvell Discovery III system controller. I modified code for Katana to make
> > > > it work for this board. The ethernet and serial are working fine but I don't
> > > > see anything in "lspci" output.
> > >
> > > Do you have any pci devices? If not, then that's to be expected.
> > > If you do, then you have something messed up in your code and they
> > > aren't being found.
> >
> > They should at least shgow the northbridge pci ids, no ?
>
> No b/c the regs for the bridge are not pci compliant so the bridge is
> "excluded" or hidden from the generic pci code (which is where lspci
> gets its info from). If it wasn't, the generic pci code would get
> confused as would the bridge.
The pegasos OF allows access to the pci config area through rtas, and those
call filter out any dangerous accesses. And since you didn't know about rtas,
i will explain for others who may be in other cases.
RTAS is a OpenFirmware/CHRP extension (RunTimeAbstraction..., not sure about
the S), which provides a set of methods which will run even when linux has
taken over and overwritten the firmware, providing stuff like halt/reset,
pci-read|write-config, nvram-fetch|store, clock access functions, ...
Friendly,
Sven Luther
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Mark A. Greer @ 2005-10-27 20:11 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051027200447.GC13847@mag.az.mvista.com>
On Thu, Oct 27, 2005 at 01:04:47PM -0700, Mark A. Greer wrote:
> On Thu, Oct 27, 2005 at 08:49:21PM +0200, Sven Luther wrote:
> > On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote:
> > > On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> > > > Hi,
> > > >
> > > > I've added platform support for a board based on MPC7447A and MV64462
> > > > Marvell Discovery III system controller. I modified code for Katana to make
> > > > it work for this board. The ethernet and serial are working fine but I don't
> > > > see anything in "lspci" output.
> > >
> > > Do you have any pci devices? If not, then that's to be expected.
> > > If you do, then you have something messed up in your code and they
> > > aren't being found.
> >
> > They should at least shgow the northbridge pci ids, no ?
>
> No b/c the regs for the bridge are not pci compliant so the bridge is
> "excluded" or hidden from the generic pci code (which is where lspci
> gets its info from). If it wasn't, the generic pci code would get
> confused as would the bridge.
Actually, I guess this is more to hide the bridge from the pci_auto when
it walks the pci buses. If the pci resources are already allocated
correctly (as in pegasos?) it may not confuse the generic pci code.
Even if it doesn't get confused, its by luck. The bridge's pci regs
are NOT pci compliant and, IMHO, its iffy to assume that things woun't
get messed up.
Mark
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Mark A. Greer @ 2005-10-27 20:04 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-embedded
In-Reply-To: <20051027184921.GA11742@localhost.localdomain>
On Thu, Oct 27, 2005 at 08:49:21PM +0200, Sven Luther wrote:
> On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote:
> > On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> > > Hi,
> > >
> > > I've added platform support for a board based on MPC7447A and MV64462
> > > Marvell Discovery III system controller. I modified code for Katana to make
> > > it work for this board. The ethernet and serial are working fine but I don't
> > > see anything in "lspci" output.
> >
> > Do you have any pci devices? If not, then that's to be expected.
> > If you do, then you have something messed up in your code and they
> > aren't being found.
>
> They should at least shgow the northbridge pci ids, no ?
No b/c the regs for the bridge are not pci compliant so the bridge is
"excluded" or hidden from the generic pci code (which is where lspci
gets its info from). If it wasn't, the generic pci code would get
confused as would the bridge.
Mark
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Sven Luther @ 2005-10-27 19:57 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Sven Luther, linuxppc-dev
In-Reply-To: <20051027192655.GA13945@lst.de>
On Thu, Oct 27, 2005 at 09:26:55PM +0200, Christoph Hellwig wrote:
> > I don't think this is really dependent on PPC_MULTIPLATFORM,
> > and the driver also supports 64460.
>
> This is not a PCI driver so adding a device table is wrong.
Sure, please provide us with a patch to add hotplug support to those platform
drivers who are not pci :)
In the meantime, this is no worse than how this was done previously, namely
having discover match the northbridge pci id.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Christoph Hellwig @ 2005-10-27 19:26 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Sven Luther
In-Reply-To: <20051025182434.GA13982@xyzzy.farnsworth.org>
> I don't think this is really dependent on PPC_MULTIPLATFORM,
> and the driver also supports 64460.
This is not a PCI driver so adding a device table is wrong.
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Sven Luther @ 2005-10-27 18:49 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051027181751.GD9628@mag.az.mvista.com>
On Thu, Oct 27, 2005 at 11:17:51AM -0700, Mark A. Greer wrote:
> On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> > Hi,
> >
> > I've added platform support for a board based on MPC7447A and MV64462
> > Marvell Discovery III system controller. I modified code for Katana to make
> > it work for this board. The ethernet and serial are working fine but I don't
> > see anything in "lspci" output.
>
> Do you have any pci devices? If not, then that's to be expected.
> If you do, then you have something messed up in your code and they
> aren't being found.
They should at least shgow the northbridge pci ids, no ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: Board based on MPC7447 and MV64462
From: Mark A. Greer @ 2005-10-27 18:17 UTC (permalink / raw)
To: Ashish Bijlani; +Cc: linuxppc-embedded
In-Reply-To: <ec55b17e0510270617k368b4555gf3f37e07cee3b4e6@mail.gmail.com>
On Thu, Oct 27, 2005 at 06:47:29PM +0530, Ashish Bijlani wrote:
> Hi,
>
> I've added platform support for a board based on MPC7447A and MV64462
> Marvell Discovery III system controller. I modified code for Katana to make
> it work for this board. The ethernet and serial are working fine but I don't
> see anything in "lspci" output.
Do you have any pci devices? If not, then that's to be expected.
If you do, then you have something messed up in your code and they
aren't being found.
> Also I don't see timer in "cat /proc/interrupts".
Neither do I... :)
Mark
^ permalink raw reply
* Re: MPC8xx support in 2.6 and [PATCH] USB host controller selection...
From: Jeff Angielski @ 2005-10-27 14:28 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: David Jander, linux-ppc-embedded
In-Reply-To: <20051027134735.8E7C6353E30@atlas.denx.de>
On Thu, 2005-10-27 at 15:47 +0200, Wolfgang Denk wrote:
> In message <200510271439.48990.david.jander@protonic.nl> you wrote:
> >
> > I am trying to figure out if kernel-2.6.x is already a (stable) option for
> > MPC8xx processors. Any hints? experience?
> > I just rsynced DENX's git tree (cg-clone will crash on a 404 error).
>
> Make sure to use current versions of git resp. cogito.
I get the same errors using using the latest versions: git version
0.99.8f and cogito-0.15. FWIW, the u-boot.git came down just fine.
> cg-clone http://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx
defaulting to local storage area
10:24:51 URL:http://www.denx.de/git/linux-2.6-denx.git/HEAD [41/41] ->
"refs/heads/.origin-fetching" [1]
progress: 1 objects, 264 bytes
walk b2304e619029b177db18dc771f2b9ba8cd273b81
progress: 3 objects, 1180 bytes
walk cb7f6ec5c2d64db78984188461dc29b72e924180
progress: 4 objects, 1424 bytes
error: The requested URL returned error: 404
Getting pack list
error: The requested URL returned error: 404
Getting alternates list
error: Unable to find ca442d313d86dc67e0a2e5d584b465bd382cbf5c under
http://www.denx.de/git/linux-2.6-denx.git/
Cannot obtain needed blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c
while processing commit cb7f6ec5c2d64db78984188461dc29b72e924180.
cg-fetch: objects fetch failed
cg-clone: fetch failed
Jeff Angielski
The PTR Group
^ permalink raw reply
* [PATCH][UPDATED] powerpc: only build idle_6xx for 6xx
From: Kumar Gala @ 2005-10-27 13:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
For the current time idle_6xx only applies to 6xx ppc32 CPUs
Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
---
commit e3b3bc6d075bd1d07caa64bcaa3add128a0cb6f3
tree e41cfdec6b3565258cb5bee14078a23f8be3b6ff
parent 0f72dedad02fc2869ddc13ff2f6998ec7dfdcbc1
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 27 Oct 2005 08:53:36 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 27 Oct 2005 08:53:36 -0500
arch/powerpc/kernel/Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -33,11 +33,12 @@ extra-y += vmlinux.lds
obj-y += process.o init_task.o time.o \
prom.o systbl.o traps.o setup-common.o
-obj-$(CONFIG_PPC32) += entry_32.o idle_6xx.o setup_32.o misc_32.o
+obj-$(CONFIG_PPC32) += entry_32.o setup_32.o misc_32.o
obj-$(CONFIG_PPC64) += setup_64.o misc_64.o
obj-$(CONFIG_PPC_OF) += prom_init.o
obj-$(CONFIG_MODULES) += ppc_ksyms.o
obj-$(CONFIG_BOOTX_TEXT) += btext.o
+obj-$(CONFIG_6xx) += idle_6xx.o
ifeq ($(CONFIG_PPC_ISERIES),y)
$(obj)/head_64.o: $(obj)/lparmap.s
^ 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