* I'm in troube to port linux on 405ep
From: Jongmin Yoon @ 2006-01-20 13:52 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]
Hello, there,
Now, I’m in trouble with porting Linux to AMCC PPC405EP.
I think u-boot was ported successfully, So, I compile linux kernel 2.6.14 with crosstool-0.38
Here is a capture of my terminial
=> tftp 200000 uImage
ENET Speed is 10 Mbps - HALF duplex connection
TFTP from server 192.168.10.100; our IP address is 192.168.10.99
Filename 'uImage'.
Load address: 0x200000
Loading: T invalid RARP header
#################################################################
#################################################################
#################################################################
################
done
Bytes transferred = 1075636 (1069b4 hex)
=> bootm 200000
## Booting image at 00200000 ...
Image Name: Linux-2.6.14-kodicom
Created: 2006-01-20 13:37:31 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1075572 Bytes = 1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Transferring control to Linux (at address 00000000) ...
Starting kernel...
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMUetio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
@
@
@
@
@
@
@
|^_���^_^_��~L~L~@p^_p^_�^_~L|�~L�^\|^_�|�^_^\p�^_?�^_~@~@|~L^_~L||
^_8~�^_|^_|^_^_^G|^_|^_8|^\~@|^_~L~L��c|~C^_�|�^_�~L�^\|^_�|�|
^_^\?�^_8�^_~@����|~Lp^\~L~@|c�~Lp^_c~@~L|p~@p|~C|�~C|^C�^_^\p��~@|
p~L|����|~C|^_�~@~L|pp��|p^C~L|^_������~L~L~Cp|�^_^\p|cp�~C|^_
|�^C�|^_^G|��~Lp^_|^_|~@|^C~L|~C|||�|^C�^\|^_?~^_8|^Cp|c~@^_^\?pp
^\�^_~@^_^\?�|||~L|^\|�c|~@~L|^_?�^_|��|�|~L|^_�p^C~L|^_���^_^_
��~L~L�p|�^C���p^C~L|^_|p������~L~L�|c��~@|p�p|^_|~L��^_p^_|
|�||^\~L|^_������~L~L�~C~L�^\||~L����|~L|^_|^_�|~@�p~@|�|~L�^\\
�|�|�^_�|^_|^_^_~L~@~@|~C|^_�~@�~L|p��p||^_|~@|�^_8~~L�|p|^C
~L|^_^\?��~@�~C|||^_|^_~L||~C|p|c|���|~C|p~L�~@||��|�p|��p�|�p�||
�^\�������|����^_~@�|��^_�������^_~@�|�^_~@�^_~@��~~
L|~L|�p~L|~L|^_^G~L|~L|^_�^C~L|^_|p������~L~L~L~C~@~@|p|^_|||^_^\~@||
^Cp��^_^_~L��^_8p|~C|^_^_||^\��p~@|�|^_^G|�~L�^\p��~@��||�~@|�
p�~C|�~L�^_cp^C~L|^_|p��^_^_��~L~L�||�^_�|~@|^_^_p�|�|^_||^_~Lp||
p~@�~L|�~L|^_�p~@�c�|~C||�c|p�|^\?~c^_p^C~L|^_���^_^_��~L~L~@~@|c|||
~@|^\|p|��^_|^_^_�^_|||~@|^Cp��~L�p~L�|^_8p|~C|~L�^_|^\�|��|
��^_|p|�|cp|^\�~L|~@^_^\?~@���|p�p�|�~L�^_|~Cp^C~L|^_���^_^_��
~L~L~C|||^_8~^_^_~L^_~@�^_|^_^_�^_|||^_^\~@|^Cp��~L�p~L��^_8p|~C|^_^_|
|^\��||�~@|^_|^_^G~@�cp|^\�~@|~@�|~L|~L||�|��~C~@|c|^_cp^C~L|^_||
p������~L~L~Lp^_^_~L|^_|p|~Cp���|�|�|�p��~C|^_|�^\~@|^_^_^_^^
G��~@||�p|�cp||^_^_~@|^_^\|�|~@�c|�~L||p��~@����^_^\�||�p
��^_p^_~@|��|����|~L|^_^_~L|^_p~Cp^C~L
I don’t know what’s wrong…
Is there anybody to give me some advises?
Regards,
I
[-- Attachment #2: Type: text/html, Size: 70698 bytes --]
^ permalink raw reply
* Re: u-boot debugging
From: Wolfgang Denk @ 2006-01-20 13:40 UTC (permalink / raw)
To: Mustafa Çayır; +Cc: linuxppc-embedded
In-Reply-To: <008501c61d8d$e35ff9f0$9e01120a@bilisim.local>
In message <008501c61d8d$e35ff9f0$9e01120a@bilisim.local> you wrote:
>
> Which tool must i use to debuggin u-boot codes. BDI2000 or windriver
> visionclick, which one do you prefer? is step by step code tracing
> possible?
I know that the BDI2000 works fine, and some people have been
successfully using the vision* tools, too (often after some
struggeling).
My personal tool of choice is the BDi2000.
Use the tool you know best...
And yes, single stepping is possible if your tool allows it.
Note that this question is off topic on this list; you should post
such questions on the U-Boot mailing list. But please ntoe that...
> Content-Type: text/html;
> charsetÿso-8859-9"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
...HTML code is strictly forbidden there!
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
If programming was easy, they wouldn't need something as complicated
as a human being to do it, now would they?
- L. Wall & R. L. Schwartz, _Programming Perl_
^ permalink raw reply
* Re: FEC ERROR
From: Wolfgang Denk @ 2006-01-20 13:37 UTC (permalink / raw)
To: feng; +Cc: Linuxppc-embedded
In-Reply-To: <43D06E4F.15E79E.30255>
In message <43D06E4F.15E79E.30255> you wrote:
>
> sometimes, My PowerPC(852T) get the following message:
And your kernel version is ... ???
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
Lots of folks confuse bad management with destiny. -- Frank Hubbard
^ permalink raw reply
* Re: [PATCH] powerpc: remove useless spinlock from mpc83xx watchdog
From: Wim Van Sebroeck @ 2006-01-20 11:55 UTC (permalink / raw)
To: Alan Cox; +Cc: Andrew Morton, Kumar Gala, linux-kernel, linuxppc-embedded
In-Reply-To: <1137708739.8471.69.camel@localhost.localdomain>
All,
> On Iau, 2006-01-19 at 14:48 -0200, Marcelo Tosatti wrote:
> > On Thu, Jan 19, 2006 at 09:49:16AM +0000, Alan Cox wrote:
> > >
> > > f = open("/dev/watchdog", O_RDWR);
> > > fork();
> > > while(1) {
> > > write(f, "Boing", 5);
> > > }
> >
> > Oops.
> >
> > At least 50% of the watchdog drivers rely solely on the "wdt_is_open"
> > atomic variable and are broken with respect to synchronization.
>
> What an excellent janitors project
I'll have a look at it from a global point of view.
Greetings,
Wim.
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-20 11:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1137708554.12998.31.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Fri, 20 Jan 2006 09:09:13 +1100
>
> > > Makes sense, since this value is right in the middle of your RAM :)
> > > What does the firmware sets the base register too ?
> > I did a readout of all AGP related registers and the base register was
> > set to 0x0, so the firmware doesn't set it up at all.
> >
> > > Can't you try to allocate some resource in the PCI area that isn't
> > > already occupied instead ?
> > I though the GART base address should be in memory space!?
>
> Euh... I was talking about the aperture base, not the GART base... (One
> is the address one the bus where the AGP area will be visible, the other
> is where the GART will be in memory, that is the table that contains the
> mapping between AGP pages and memory pages).
Doh! :) Actually I meant the aperture base. That was a communication error
between brain and hands. :)
> > Sorry for this dumb question: how can I allocate a resource in the PCI
> > area? I'm not yet familiar with the whole Linux PCI/MM API. :) With
> > something like pci_alloc_consistent()?
>
> Nope... look at drivers/pci/setup-res.c how it does for allocating new
> resources for PCI devices.
I guess you mean something like this code snipped from the efficeon-agp.c
source code (with pci_assign_resource()):
---
/*
* The following fixes the case where the BIOS has "forgotten" to
* provide an address range for the GART.
* 20030610 - hamish@zot.org
*/
r = &pdev->resource[0];
if (!r->start && r->end) {
if(pci_assign_resource(pdev, 0)) {
printk(KERN_ERR PFX "could not assign resource 0\n");
return -ENODEV;
}
}
/*
* If the device has not been properly setup, the following will catch
* the problem and should stop the system from crashing.
* 20030610 - hamish@zot.org
*/
if (pci_enable_device(pdev)) {
printk(KERN_ERR PFX "Unable to Enable PCI device\n");
return -ENODEV;
}
/* Fill in the mode register */
if (cap_ptr) {
pci_read_config_dword(pdev,
bridge->capndx+PCI_AGP_STATUS, &bridge->mode);
}
pci_set_drvdata(pdev, bridge);
----
BTW: I took a look at the PCI resources list of the AmigaOne and found out
that the resources of the AGP graphic card are allocated to bus 0 (PCI
only). IMHO their allocation should be assigned to bus 1 (AGP) (at least
this is the case on x86!?), so I think this should be fixed. Is my
assumption correct?
Thanks!
Gerhard
--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
^ permalink raw reply
* [PATCH] sound/ppc/pmac.c typo.
From: Stelian Pop @ 2006-01-20 10:35 UTC (permalink / raw)
To: linuxppc-dev
In 2.6.16-rc1 there is a small typo introduced by the 'Remove device_node addrs/n_addr' changes
which prevents my Powerbook G4 sound from working:
Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
snd: can't request rsrc 0 (Sound Control: 0x80000000:80004fff)
ALSA device list:
No soundcards found.
The patch below fixes it. Of course, the patch fixing the i2c issues
('i2c_smbus_write_i2c_block_data' patch) needs to be applied to in order for
the sound to completly work.
Signed-off-by: Stelian Pop <stelian@popies.net>
diff -r ad1abd4058ea sound/ppc/pmac.c
--- a/sound/ppc/pmac.c Fri Jan 20 11:02:26 2006 +0100
+++ b/sound/ppc/pmac.c Fri Jan 20 11:13:55 2006 +0100
@@ -1217,7 +1217,7 @@
goto __error;
}
for (i = 0; i < 3; i ++) {
- if (of_address_to_resource(np->parent, i,
+ if (of_address_to_resource(np, i,
&chip->rsrc[i])) {
printk(KERN_ERR "snd: can't translate rsrc "
" %d (%s)\n", i, rnames[i]);
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: [PATCH] x_tables: fix alignment on [at least] ppc32
From: David S. Miller @ 2006-01-20 9:43 UTC (permalink / raw)
To: mikpe; +Cc: laforge, linuxppc-dev, netfilter-devel, linux-kernel
In-Reply-To: <17360.44337.425946.347577@alkaid.it.uu.se>
From: Mikael Pettersson <mikpe@csd.uu.se>
Date: Fri, 20 Jan 2006 10:28:17 +0100
> ACK. Both Harald's patch and DaveM's simplification of it
> (simply s/void */u_int64_t/g in XT_ALIGN()) fix the iptables
> problems on my ppc32 box.
Thanks for testing.
^ permalink raw reply
* Re: [PATCH] x_tables: fix alignment on [at least] ppc32
From: Mikael Pettersson @ 2006-01-20 9:28 UTC (permalink / raw)
To: David S. Miller; +Cc: laforge, linuxppc-dev, netfilter-devel, linux-kernel
In-Reply-To: <20060119.165635.104653932.davem@davemloft.net>
David S. Miller writes:
> From: Harald Welte <laforge@netfilter.org>
> Date: Fri, 20 Jan 2006 01:45:12 +0100
>
> > [NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32
> >
> > To keep backwards compatibility with old iptables userspace programs,
> > the new XT_ALIGN macro always has to return the same value as IPT_ALIGN,
> > IP6T_ALIGN or ARPT_ALIGN in previous kernels.
> >
> > However, in those kernels the macro was defined in dependency to the
> > respective layer3 specifi data structures, which we can no longer do with
> > x_tables.
> >
> > The fix is an ugly kludge, but it has been tested to solve the problem. Yet
> > another reason to move away from the current {ip,ip6,arp,eb}tables like
> > data structures.
> >
> > Signed-off-by: Harald Welte <laforge@netfilter.org>
>
> Harald, I'm going to modify this to just use u_int64_t as that
> should be totally sufficient.
ACK. Both Harald's patch and DaveM's simplification of it
(simply s/void */u_int64_t/g in XT_ALIGN()) fix the iptables
problems on my ppc32 box.
/Mikael
^ permalink raw reply
* serial drivers for MPC860Tin linux 2.6.13
From: bharathi kandimalla @ 2006-01-20 8:54 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org; +Cc: ram krishna, jagadish
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
> Hi
> We are able to port the linux 2.6 in our target board.As the
MPC860T
> has 4 SCC ports and two SMC ports.I want to up all the SMC and SCC
> ports.When I am selecting all the options in the kernel configuration
> It is getting hanged.
> did n't see any mknod in the code
> w how can I know ttyCPM2 is for SMC2
> ttyCPM1 is for SMC1 like thatI
> and they mentioned only major number is 204
> mainor number is 46
> As we want to use 6 ports.We want 6 minor numbers
> regards
bharthi
---------------------------------
Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP.
[-- Attachment #2: Type: text/html, Size: 941 bytes --]
^ permalink raw reply
* MPC5200, PCI, udelay(10)
From: Roman Kuzmenko @ 2006-01-20 8:31 UTC (permalink / raw)
To: Linuxppc-embedded
Hello.
Please, help me to investigate why the delays present in the
"mpc5xxx_read_config_dword" and "mpc5xxx_write_config_dword" functions
in the "arch/ppc/kernel/mpc52xx_pci.c" file.
I.e.
==========================
*(volatile u32 *)MPC5xxx_PCI_CAR = 0;
> udelay(10);
return 0;
==========================
I was neither able to find any reference at the MPC5200 documentation
supplied by FreeScale nor reproduce any error with these lines got
removed.
Thank you.
--
Roman Kuzmenko <roman.kuzmenko@auriga.ru>
Auriga, Inc.
^ permalink raw reply
* u-boot debugging
From: Mustafa Çayır @ 2006-01-20 6:51 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 162 bytes --]
Hi,
Which tool must i use to debuggin u-boot codes. BDI2000 or windriver visionclick, which one do you prefer? is step by step code tracing possible?
thanks
[-- Attachment #2: Type: text/html, Size: 659 bytes --]
^ permalink raw reply
* serial driver for MPC860T in linux 2.6.13
From: bharathi kandimalla @ 2006-01-20 6:30 UTC (permalink / raw)
To: Linuxppc-embedded; +Cc: jagadish
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]
Hi
We are able to port the linux 2.6 in our target board.As the
MPC860T has 4 SCC ports and two SMC ports.I want to up all the SMC and SCC
ports.When I am selecting all the options in the kernel configuration
It is getting hanged.
I did n't see any mknod in the code
how can I know ttyCPM2 is for SMC2.At the time of ramdisk building I have created the the softlink to ttyCPM2 ->console
ttyCPM1 is for SMC1 like that
and they mentioned only major number is 204 minor number is 46
As we want to use 6 ports.We want 6 minor numbers
when I am selectind SMC and all SCC' s the o.s is up in the target board( as the program did not have any portpin configuartions for the SCC's)
when I am selecting SMC1 and SMC2 it is getting hanged
regards
Bharathi
---------------------------------
Yahoo! Photos
Got holiday prints? See all the ways to get quality prints in your hands ASAP.
[-- Attachment #2: Type: text/html, Size: 1368 bytes --]
^ permalink raw reply
* Re: [PATCH] PPC32 CPM_UART: update to utilize the new TTY flip API
From: Paul Mackerras @ 2006-01-20 5:05 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060115154409.1627.95041.stgit@vitb.dev.rtsoft.ru>
Vitaly Bordug writes:
> This replaces old direct usage of tty->flip stuff with relative flip API
> calls.
Could I have a Signed-off-by line from you for it please?
Paul.
^ permalink raw reply
* FEC ERROR
From: feng @ 2006-01-20 4:14 UTC (permalink / raw)
To: Linuxppc-embedded
Hi,
sometimes, My PowerPC(852T) get the following message:
FEC ENET: rcv is not +last
FEC ERROR 43200000
FEC ENET: rcv is not +last
FEC ERROR 43200000
FEC ENET: rcv is not +last
FEC ERROR 43200000
...
What does this mean.
Best regards
^ permalink raw reply
* Re: [PATCH] x_tables: fix alignment on [at least] ppc32
From: David S. Miller @ 2006-01-20 0:56 UTC (permalink / raw)
To: laforge; +Cc: linuxppc-dev, netfilter-devel, linux-kernel, mikpe
In-Reply-To: <20060120004512.GT4603@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Fri, 20 Jan 2006 01:45:12 +0100
> [NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32
>
> To keep backwards compatibility with old iptables userspace programs,
> the new XT_ALIGN macro always has to return the same value as IPT_ALIGN,
> IP6T_ALIGN or ARPT_ALIGN in previous kernels.
>
> However, in those kernels the macro was defined in dependency to the
> respective layer3 specifi data structures, which we can no longer do with
> x_tables.
>
> The fix is an ugly kludge, but it has been tested to solve the problem. Yet
> another reason to move away from the current {ip,ip6,arp,eb}tables like
> data structures.
>
> Signed-off-by: Harald Welte <laforge@netfilter.org>
Harald, I'm going to modify this to just use u_int64_t as that
should be totally sufficient.
It is the largest type, and will produce the desired results without
the silly structure.
Some malloc() implementations use "long double" to figure out the
largest type size and alignment requirements any C type might have
on the machine. But there is no reason to use that here.
^ permalink raw reply
* [PATCH] x_tables: fix alignment on [at least] ppc32 (was Re: 2.6.16-rc1: iptables broken on ppc32?)
From: Harald Welte @ 2006-01-20 0:45 UTC (permalink / raw)
To: netfilter-devel, Mikael Pettersson, linuxppc-dev, linux-kernel
Cc: David Miller
In-Reply-To: <20060118150158.GL4603@sunbeam.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]
Hi,
the patch below fixes the problem on ppc32. Dave: Please apply.
[NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32
To keep backwards compatibility with old iptables userspace programs,
the new XT_ALIGN macro always has to return the same value as IPT_ALIGN,
IP6T_ALIGN or ARPT_ALIGN in previous kernels.
However, in those kernels the macro was defined in dependency to the
respective layer3 specifi data structures, which we can no longer do with
x_tables.
The fix is an ugly kludge, but it has been tested to solve the problem. Yet
another reason to move away from the current {ip,ip6,arp,eb}tables like
data structures.
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit 470faeb379560fe877b685ca69be6a7e4f0e91ed
tree 5732ecd9bcab28469805752514e5c57ba26189a1
parent 44718bbfa186d58477163418d37df173aa2dd079
author Harald Welte <laforge@netfilter.org> Fri, 20 Jan 2006 01:44:24 +0100
committer Harald Welte <laforge@netfilter.org> Fri, 20 Jan 2006 01:44:24 +0100
include/linux/netfilter/x_tables.h | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index 472f048..65f9cd8 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -19,7 +19,20 @@ struct xt_get_revision
/* For standard target */
#define XT_RETURN (-NF_REPEAT - 1)
-#define XT_ALIGN(s) (((s) + (__alignof__(void *)-1)) & ~(__alignof__(void *)-1))
+/* this is a dummy structure to find out the alignment requirement for a struct
+ * containing all the fundamental data types that are used in ipt_entry, ip6t_entry
+ * and arpt_entry. This sucks, and it is a hack. It will be my personal pleasure
+ * to remove it -HW */
+struct _xt_align
+{
+ u_int8_t u8;
+ u_int16_t u16;
+ u_int32_t u32;
+ u_int64_t u64;
+};
+
+#define XT_ALIGN(s) (((s) + (__alignof__(struct _xt_align)-1)) \
+ & ~(__alignof__(struct _xt_align)-1))
/* Standard return verdict, or do jump. */
#define XT_STANDARD_TARGET ""
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] powerpc: remove useless spinlock from mpc83xx watchdog
From: Alan Cox @ 2006-01-19 22:12 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Andrew Morton, Kumar Gala, wim, linux-kernel, linuxppc-embedded
In-Reply-To: <20060119164811.GB4418@dmt.cnet>
On Iau, 2006-01-19 at 14:48 -0200, Marcelo Tosatti wrote:
> On Thu, Jan 19, 2006 at 09:49:16AM +0000, Alan Cox wrote:
> >
> > f = open("/dev/watchdog", O_RDWR);
> > fork();
> > while(1) {
> > write(f, "Boing", 5);
> > }
>
> Oops.
>
> At least 50% of the watchdog drivers rely solely on the "wdt_is_open"
> atomic variable and are broken with respect to synchronization.
What an excellent janitors project
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Benjamin Herrenschmidt @ 2006-01-19 22:09 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <15255.1137667967@www31.gmx.net>
On Thu, 2006-01-19 at 11:52 +0100, Gerhard Pircher wrote:
> > > I set the AGP aperture base register and agp_bridge->gart_bus_addr to
> > > 0x01000000 (>=16MB) (trial and error :-) and it seems to work with
> > > cant_use_aperture=1
> >
> > Makes sense, since this value is right in the middle of your RAM :) What
> > does the firmware sets the base register too ?
> I did a readout of all AGP related registers and the base register was set
> to 0x0, so the firmware doesn't set it up at all.
>
> > Can't you try to allocate some resource in the PCI area that isn't
> > already occupied instead ?
> I though the GART base address should be in memory space!?
Euh... I was talking about the aperture base, not the GART base... (One
is the address one the bus where the AGP area will be visible, the other
is where the GART will be in memory, that is the table that contains the
mapping between AGP pages and memory pages).
> Sorry for this dumb question: how can I allocate a resource in the PCI area?
> I'm not yet familiar with the whole Linux PCI/MM API. :) With something like
> pci_alloc_consistent()?
Nope... look at drivers/pci/setup-res.c how it does for allocating new
resources for PCI devices.
> > (and without the modification in drm_vm.c). Even the X
> > > server maps all the data to this address and displays a login screen.
> > > Unfortunately it always freezes in. I guess this is due to the missing
> > > GART flush functionality. So I have to get this working first.
> >
> > Yah, that would be pretty bad...
> Indeed! :)
>
> Gerhard
>
^ permalink raw reply
* Re: [RFC][Patch] pci_0 pci_1 mixup in ppc/platforms/chestnut.c
From: Mark A. Greer @ 2006-01-19 18:29 UTC (permalink / raw)
To: Eric Sesterhenn / snakebyte; +Cc: linuxppc-dev
In-Reply-To: <1137679159.22607.5.camel@alice>
On Thu, Jan 19, 2006 at 02:59:19PM +0100, Eric Sesterhenn / snakebyte wrote:
<snip>
> --- linux-2.6.15-git11/arch/ppc/platforms/chestnut.c.orig 2006-01-19 14:54:59.000000000 +0100
> +++ linux-2.6.15-git11/arch/ppc/platforms/chestnut.c 2006-01-19 14:55:25.000000000 +0100
> @@ -199,7 +199,7 @@ chestnut_setup_bridge(void)
> si.mpsc_options[i] = MV64360_MPSC2MEM_SNOOP_NONE;
> si.idma_options[i] = MV64360_IDMA2MEM_SNOOP_NONE;
>
> - si.pci_1.acc_cntl_options[i] =
> + si.pci_0.acc_cntl_options[i] =
> MV64360_PCI_ACC_CNTL_SNOOP_NONE |
> MV64360_PCI_ACC_CNTL_SWAP_NONE |
> MV64360_PCI_ACC_CNTL_MBURST_128_BYTES |
>
Good catch. Note that the tree you should be submitting patches against
is the powerpc.git tree. In this case, though, I expect the patch to apply
cleanly to that tree.
Also, there are 2 place where that occurs. Mind fixing both?
Mark
^ permalink raw reply
* Re: [PATCH] powerpc: remove useless spinlock from mpc83xx watchdog
From: Marcelo Tosatti @ 2006-01-19 16:48 UTC (permalink / raw)
To: Alan Cox; +Cc: Andrew Morton, Kumar Gala, wim, linux-kernel, linuxppc-embedded
In-Reply-To: <1137664156.8471.16.camel@localhost.localdomain>
On Thu, Jan 19, 2006 at 09:49:16AM +0000, Alan Cox wrote:
> On Iau, 2006-01-19 at 00:58 -0600, Kumar Gala wrote:
> > Since we can only open the watchdog once having a spinlock to protect
> > multiple access is pointless.
> >
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> NAK
>
> This is a common mistake.
>
> open is called on the open() call and is indeed in this case 'single
> open', but file handles can be inherited and many users may have access
> to a single file handle.
>
> eg
>
> f = open("/dev/watchdog", O_RDWR);
> fork();
> while(1) {
> write(f, "Boing", 5);
> }
Oops.
At least 50% of the watchdog drivers rely solely on the "wdt_is_open"
atomic variable and are broken with respect to synchronization.
^ permalink raw reply
* Re: [PATCH] powerpc: remove useless spinlock from mpc83xx watchdog
From: Kumar Gala @ 2006-01-19 14:21 UTC (permalink / raw)
To: Alan Cox; +Cc: Andrew Morton, wim, LKML List, Linuxppc-Embedded ((E-Mail))
In-Reply-To: <1137664156.8471.16.camel@localhost.localdomain>
On Jan 19, 2006, at 3:49 AM, Alan Cox wrote:
> On Iau, 2006-01-19 at 00:58 -0600, Kumar Gala wrote:
>> Since we can only open the watchdog once having a spinlock to protect
>> multiple access is pointless.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> NAK
>
> This is a common mistake.
>
> open is called on the open() call and is indeed in this case 'single
> open', but file handles can be inherited and many users may have
> access
> to a single file handle.
>
> eg
>
> f = open("/dev/watchdog", O_RDWR);
> fork();
> while(1) {
> write(f, "Boing", 5);
> }
>
> Alan
Thanks, you learn something new every day.
- kumar
^ permalink raw reply
* [RFC][Patch] pci_0 pci_1 mixup in ppc/platforms/chestnut.c
From: Eric Sesterhenn / snakebyte @ 2006-01-19 13:59 UTC (permalink / raw)
To: linuxppc-dev
hi,
i am currently toying around with cp-miner
( http://opera.cs.uiuc.edu/Projects/ARTS/CP-Miner.htm )
and came across chesnut.c
/* setup only PCI bus 0 (bus 1 not used) */
si.pci_0.enable_bus = 1;
si.pci_0.pci_io.cpu_base = CHESTNUT_PCI0_IO_PROC_ADDR;
si.pci_0.pci_io.pci_base_hi = 0;
si.pci_0.pci_io.pci_base_lo = CHESTNUT_PCI0_IO_PCI_ADDR;
si.pci_0.pci_io.size = CHESTNUT_PCI0_IO_SIZE;
[...SNIP ... ]
si.pci_1.acc_cntl_options[i] =
MV64360_PCI_ACC_CNTL_SNOOP_NONE |
MV64360_PCI_ACC_CNTL_SWAP_NONE |
[...]
since the commentary clearly states that only pci_0 is
used i assume this is a bug and the si.pci_0.acc_cntl_options
should be set?
Please cc me on replies since i am not subscribed.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
--- linux-2.6.15-git11/arch/ppc/platforms/chestnut.c.orig 2006-01-19 14:54:59.000000000 +0100
+++ linux-2.6.15-git11/arch/ppc/platforms/chestnut.c 2006-01-19 14:55:25.000000000 +0100
@@ -199,7 +199,7 @@ chestnut_setup_bridge(void)
si.mpsc_options[i] = MV64360_MPSC2MEM_SNOOP_NONE;
si.idma_options[i] = MV64360_IDMA2MEM_SNOOP_NONE;
- si.pci_1.acc_cntl_options[i] =
+ si.pci_0.acc_cntl_options[i] =
MV64360_PCI_ACC_CNTL_SNOOP_NONE |
MV64360_PCI_ACC_CNTL_SWAP_NONE |
MV64360_PCI_ACC_CNTL_MBURST_128_BYTES |
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-19 10:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1137664796.4823.214.camel@localhost.localdomain>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1234 bytes --]
> > I set the AGP aperture base register and agp_bridge->gart_bus_addr to
> > 0x01000000 (>=16MB) (trial and error :-) and it seems to work with
> > cant_use_aperture=1
>
> Makes sense, since this value is right in the middle of your RAM :) What
> does the firmware sets the base register too ?
I did a readout of all AGP related registers and the base register was set
to 0x0, so the firmware doesn't set it up at all.
> Can't you try to allocate some resource in the PCI area that isn't
> already occupied instead ?
I though the GART base address should be in memory space!?
Sorry for this dumb question: how can I allocate a resource in the PCI area?
I'm not yet familiar with the whole Linux PCI/MM API. :) With something like
pci_alloc_consistent()?
> > (and without the modification in drm_vm.c). Even the X
> > server maps all the data to this address and displays a login screen.
> > Unfortunately it always freezes in. I guess this is due to the missing
> > GART flush functionality. So I have to get this working first.
>
> Yah, that would be pretty bad...
Indeed! :)
Gerhard
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
^ permalink raw reply
* Fw: [Bugme-new] [Bug 5679] New: Kernel fails to boot
From: Andrew Morton @ 2006-01-19 10:42 UTC (permalink / raw)
To: linuxppc-dev
Begin forwarded message:
Date: Tue, 29 Nov 2005 17:17:23 -0800
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 5679] New: Kernel fails to boot
http://bugzilla.kernel.org/show_bug.cgi?id=5679
Summary: Kernel fails to boot
Kernel Version: all > 2.6.8
Status: NEW
Severity: blocking
Owner: platform_ppc-32@kernel-bugs.osdl.org
Submitter: t.visconti@cantierecreativo.fi.it
Most recent kernel where this bug did not occur: 2.6.8
Distribution: Gentoo 2005.1 - Ubuntu 5.10 - Debian Etch
Hardware Environment: PowerBook 12" (july 2005), italian
Problem Description: With these distributions and with every kernel version
newer than 2.6.8, kernel fails to boot.
There are no error messages, the pc 'freeze' just before the page with the
penguin logo, this is the freezed page:
======================
Welcome to Linux, kernel 2.6.14
linked at : 0xc0000000
frame buffer at : 0xa0008000 (phys), 0xd0008000 (log)
klimit : 0xc042c018
MSR : 0x00003030
HID0 : 0x8410c0bc
pmac_init(): exit
id mach(): done
MMU:enter
MMU: hw init
hash:enter
hash:find piece
hash:patch
hash:done
MMU:mapin
MMU:setio
MMU:exit <-(here it stops)
======================
Sometimes the final word 'exit' is not clear (some pixels are in strange positions)
Steps to reproduce: boot with a cd of mentioned distributions or with any kernel
version newer than 2.6.8
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: [PATCH] powerpc: remove useless spinlock from mpc83xx watchdog
From: Alan Cox @ 2006-01-19 9:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, wim, linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0601190057130.8484-100000@gate.crashing.org>
On Iau, 2006-01-19 at 00:58 -0600, Kumar Gala wrote:
> Since we can only open the watchdog once having a spinlock to protect
> multiple access is pointless.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
NAK
This is a common mistake.
open is called on the open() call and is indeed in this case 'single
open', but file handles can be inherited and many users may have access
to a single file handle.
eg
f = open("/dev/watchdog", O_RDWR);
fork();
while(1) {
write(f, "Boing", 5);
}
Alan
^ 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