* Re: Virtex-4 TEMAC device driver available?
From: Yoshio Kashiwagi @ 2006-02-19 11:39 UTC (permalink / raw)
To: S. Egbert, linuxppc-embedded
In-Reply-To: <43F7CB11.5000202@sbcglobal.net>
Hello Steve San,
Strictly, GSRD differs from TEMAC.
Although both are embedded TEMAC is used in Virtex4, GSRD accesses
direct memory through MPMC. MPMC is a multi-port memory controller
for GSRD to access direct memory.
http://www.xilinx.com/esp/wired/optical/xlnx_net/gsrd_download.htm
Download of GSRD is linked out of the above-mentioned URL, and
becomes a place to be logged in (Registration for downloading the
reference design short cut).
http://www.xilinx.com/xlnx/xil_entry2.jsp?sMode=login&group=gsrd
Linux2.4 driver is contained in this GSRD. However, this Linux2.4
driver (adapter.c) has the fault which does not operate correctly,
when a 100BASE hub is connected. In order to correct this problem,
it is necessary to add the interrupt handling routine of PHY.
Although this GSRD is a reference design more nearly high-speed
than TEMAC, many FPGA resources are used for it.
I am going to create a TEMAC driver (Linux2.6) by a scratch, I
cannot make time for it now. Since it is due to make by the end of
this month, if it is completed, I'll announce it to this mailing
list.
I'll write the Linux2.6 TEMAC driver corresponding to the following
reference designs.
http://direct.xilinx.com/bvdocs/appnotes/xapp902.pdf
http://www.xilinx.com/bvdocs/appnotes/xapp902.zip
(The Linux driver is not contained in this reference design)
Best Regards,
Yoshio Kashiwagi - Nissin Systems
> Dear Kashiwagi-San,
>
> I noticed in your posting over at linuxppc-embedded in Jan 2006 about
a
> Xilinx demo code for the TEMAC driver.
>
> So, I pulled the
> http://www.xilinx.co.jp/ise/embedded/EDK/71i/mpmc_7_1_2.zip file and
> browsed it.
>
> Do you know where one can get a patch for Linux 2.4?
>
> Thank you,
>
> Steve Egbert
>
> --
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GAT d- s++: !a C+++ UL++++ P+++ L+++ E W+++ N+ o++ K+++ w--
> O- M+ V- PS PE++ Y+ PGP++ t++ 5++ X++ R tv- b++ DI+ D+
> G++ e* h++ r+++ z
> ------END GEEK CODE BLOCK------
> GPG Public Key: http://www.egbert.net/pgp
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: 2.6.16-rc4: known regressions
From: Pekka Enberg @ 2006-02-19 11:06 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, len.brown, Dmitry Torokhov, linux-acpi,
John Stultz, Meelis Roos, gregkh, Linux Kernel Mailing List,
linuxppc-dev, Linus Torvalds, linux-input, Sanjoy Mahajan
In-Reply-To: <20060217231444.GM4422@stusta.de>
On 2/18/06, Adrian Bunk <bunk@stusta.de> wrote:
> Subject : gnome-volume-manager broken on powerpc since 2.6.16-rc1
> References : http://bugzilla.kernel.org/show_bug.cgi?id=3D6021
> Submitter : John Stultz <johnstul@us.ibm.com>
> Status : still present in -git two days ago
This is not ppc only. I have the exact same problem on Gentoo
Linux/x86. No ipod events on 2.6.16-rc1, whereas 2.6.15 works fine.
Haven't had the time to investigate further yet, sorry.
Pekka
^ permalink raw reply
* altivec_unavailable_exception Oopses
From: Alan Curry @ 2006-02-19 4:10 UTC (permalink / raw)
To: linuxppc-dev
When running a CONFIG_ALTIVEC=n kernel on a G4, altivec_unavailable_exception
should send a SIGILL to any process that tries to execute a vector
instruction in user mode. For some reason, it's not doing that. Instead, it
either Oopses or continually retries the faulting instruction. Sometimes it
also prints the message indicating that fault happened in kernel mode.
I've tried 2.6.15.4 and 2.6.16-rc4. Although the log messages look different,
the general idea is the same.
Log messages from 2.6.15.4:
AltiVec used in kernel (task=dd77a050, pc=0)
AltiVec used in kernel (task=dd77a050, pc=0)
AltiVec used in kernel (task=dd77a050, pc=0)
AltiVec used in kernel (task=dd77a050, pc=0)
AltiVec used in kernel (task=dd77a050, pc=0)
AltiVec used in kernel (task=dd77a050, pc=0)
AltiVec used in kernel (task=dd77a050, pc=0)
AltiVec used in kernel (task=dd77a050, pc=0)
AltiVec used in kernel (task=dd77a050, pc=0)
[...much later, on another attempt...]
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0005ABC LR: C0004A5C SP: D17E9F20 REGS: d17e9e70 TRAP: 0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000088, DSISR: 40000000
TASK = c93ad830[11262] 'mplayer' THREAD: d17e8000
Last syscall: 174
GPR00: C0004A5C D17E9F20 C93AD830 00000004 00000004 00030001 00000000 0F9E4C00
GPR08: 10530000 C0004A5C 00009032 C0320000 093ADA00 1053A930 00000001 00000000
GPR16: 10097774 00000000 00000000 10090000 00000000 30017480 00000000 7FA87A74
GPR24: 00000004 00000004 7FA87B14 7FA87A60 7FA87A74 300269E8 0FAFBA1C 00000004
NIP [c0005abc] altivec_unavailable_exception+0x24/0x94
LR [c0004a5c] ret_from_except+0x0/0x1c
Call trace:
[c0004a5c] ret_from_except+0x0/0x1c
Log messages from 2.6.16-rc4:
Unable to handle kernel paging request for data at address 0x00000088
Faulting instruction address: 0xc000e5a0
Oops: Kernel access of bad area, sig: 11 [#1]
Modules linked in: ipv6 ip_nat_tftp ip_conntrack_tf tp ip_nat_irc ip_conntrack_irc ip_nat_ftp ip_conntrack_ftp ip_nat_amanda ip_conntrack_amanda ipt_MASQUERADE iptable_nat ip_nat ip_conntrack nfnetlink ip_tables x_tables snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore uhci_hcd ohci_hcd usbcore ohci1394 ieee1394 unix dm_mod mv643xx_eth via_rhine psmouse i8042 atkbd serio libps2
NIP: C000E5A0 LR: C000F540 CTR: 00000000
REGS: d4e49e70 TRAP: 0300 Not tainted (2.6.16-rc4)
MSR: 00009032 <EE,ME,IR,DR> CR: 44000482 XER: 00000000
DAR: 00000088, DSISR: 40000000
TASK = dbc29440[1347] 'mplayer' THREAD: d4e48000
GPR00: C000F540 D4E49F20 DBC29440 00000004 00000004 00030001 00000000 0F9E4C00
GPR08: 104C0000 C000F540 00009032 C000E580 1BC29618 104CC6C0 100A0000 FFFFFFFF
GPR16: 00000000 00000000 00000000 10090000 00000000 30017720 10007CD0 103A3BA8
GPR24: 103A3C38 00000006 7FDB2B8C 00000000 7FDB2AF4 00000006 00000001 00000004
NIP [C000E5A0] altivec_unavailable_exception+0x20/0x84
LR [C000F540] ret_from_except+0x0/0x14
Call Trace:
[D4E49F20] [10003D85] 0x10003d85 (unreliable)
[D4E49F40] [C000F540] ret_from_except+0x0/0x14
--- Exception: f21 at 0x10014524
LR = 0x100144a0
Instruction dump:
bba10014 3863eba8 38210020 4bfff190 9421ffe0 7c0802a6 3ca00003 7c641b78
93e1001c 60a50001 90010024 7c7f1b78 <80030084> 38600004 70094000 801f0080
[...later, on second attempt...]
Oops: Unrecoverable VMX/Altivec Unavailable Exception, sig: 6 [#2]
Modules linked in: ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc ipv6 ip_nat_tftp ip_conntrack_tftp ip_nat_irc ip_conntrack_irc ip_nat_ftp ip_conntrack_ftp ip_nat_amanda ip_conntrack_amanda ipt_MASQUERADE iptable_nat ip_nat ip_conntrack nfnetlink ip_tables x_tables snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore uhci_hcd ohci_hcd usbcore ohci1394 ieee1394 unix dm_mod mv643xx_eth via_rhine psmouse i8042 atkbd serio libps2
NIP: 00000000 LR: 00000000 CTR: 00000000
REGS: 105bd458 TRAP: 0000 Not tainted (2.6.16-rc4)
MSR: 00000000 <> CR: 00000000 XER: 00000000
TASK = d3106050[1428] 'mplayer' THREAD: dc664000
GPR00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR08: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
NIP [00000000] 0x0
LR [00000000] 0x0
Call Trace:
[DC665ED0] [C0007674] show_stack+0x5c/0x184 (unreliable)
[DC665F00] [C00070B0] show_regs+0x180/0x1b8
[DC665F20] [C000D788] die+0x7c/0xe0
[DC665F40] [C000F540] ret_from_except+0x0/0x14
--- Exception: f21 at 0x10015374
LR = 0x10006438
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
/proc/cpuinfo while running the no-altivec 2.6.16-rc4:
processor : 0
cpu : 7447/7457
clock : 999.999990MHz
revision : 0.1 (pvr 8002 0101)
bogomips : 66.56
timebase : 33333333
machine : CHRP Pegasos2
^ permalink raw reply
* Virtex-4 TEMAC device driver available?
From: S. Egbert @ 2006-02-19 1:36 UTC (permalink / raw)
To: linuxppc-embedded
Dear Mr. Lynch,
I noticed your posting on Linux PPC embedded news list in Jan 2006 about
the TEMAC driver for Linux.
So, I pulled a copy of Xilinx driver
(http://www.xilinx.co.jp/ise/embedded/EDK/71i/mpmc_7_1_2.zip) and
browsed it.
Did you have any luck thus far with the Linux 2.4 patch?
Coordially,
Steve
---
Steve Egbert
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT d- s++: !a C+++ UL++++ P+++ L+++ E W+++ N+ o++ K+++ w--
O- M+ V- PS PE++ Y+ PGP++ t++ 5++ X++ R tv- b++ DI+ D+
G++ e* h++ r+++ z
------END GEEK CODE BLOCK------
GPG Public Key: http://www.egbert.net/pgp
^ permalink raw reply
* Virtex-4 TEMAC device driver available?
From: S. Egbert @ 2006-02-19 1:34 UTC (permalink / raw)
To: linuxppc-embedded
Dear Kashiwagi-San,
I noticed in your posting over at linuxppc-embedded in Jan 2006 about a
Xilinx demo code for the TEMAC driver.
So, I pulled the
http://www.xilinx.co.jp/ise/embedded/EDK/71i/mpmc_7_1_2.zip file and
browsed it.
Do you know where one can get a patch for Linux 2.4?
Thank you,
Steve Egbert
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT d- s++: !a C+++ UL++++ P+++ L+++ E W+++ N+ o++ K+++ w--
O- M+ V- PS PE++ Y+ PGP++ t++ 5++ X++ R tv- b++ DI+ D+
G++ e* h++ r+++ z
------END GEEK CODE BLOCK------
GPG Public Key: http://www.egbert.net/pgp
^ permalink raw reply
* Re: Re: Instruction Set Simulator
From: Mark Chambers @ 2006-02-18 20:56 UTC (permalink / raw)
To: jeanwelly, linuxppc-embedded
In-Reply-To: <200602182148070938125@126.com>
> Hi, All
> Seems PearPC is big package, is there any small one as
> simulator which can be use in Linux or Win? Thank you!
>
I've never tried it myself, but isn't there 'target sim' under gdb?
Mark C.
^ permalink raw reply
* Re: Re: Instruction Set Simulator
From: jeanwelly @ 2006-02-18 13:48 UTC (permalink / raw)
To: David H. Lynch Jr., linuxppc-embedded@ozlabs.org
In-Reply-To: <43F6D8A3.3030907@dlasys.net>
SGksICBBbGwNClNlZW1zICBQZWFyUEMgIGlzICBiaWcgIHBhY2thZ2UsICBpcyAgdGhlcmUgIGFu
eSAgc21hbGwgIG9uZSAgYXMgIHNpbXVsYXRvciAgd2hpY2ggIGNhbiAgYmUgIHVzZSAgaW4gIExp
bnV4ICBvciAgV2luPyAgVGhhbmsgIHlvdSEgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPg0K
PkkgIGxvb2tlZCAgYXQgIFBlYXJQQyAgcnVubmluZyAgb24gIGFuICBYODYgIGFuZCAgd2FzICBh
YmxlICB0byAgZ2V0ICBEZWJpYW4gIHBwYw0KPkxpbnV4ICBpbnN0YWxsZWQgIG9uICBpdC4NCj4N
Cj5JICB3YXMgIGxvb2tpbmcgIHRvICB1c2UgIGl0ICBhcyAgYSAgcHNldWRvICBuYXRpdmUgIHBs
YXRmb3JtICB0byAgZG8gIGNyb3NzcGxhdGZvcm0NCj5kZXZlbG9wbWVudC4NCj5UaGUgIHBlcmZv
cm1hbmNlICB3YXMgIHNsb3cuICBCdXQgIG90aGVyd2lzZSAgaXQgIHdhcyAgaW50ZXJlc3Rpbmcu
DQo+RXZlbnR1YWxseSAgSSAgYm91Z2h0ICBhICBwb3dlcmJvb2sgIG9mZiAgZUJheSAgY2hlYXAu
DQo+DQo+TW9zdCAgb2YgIHRoZSAgdGltZSAgSSAgdXNlICBjcm9zcyAgdG9vbHMsICBidXQgIG5v
dyAgYW5kICB0aGVuICBpdCAgaXMgIHVzZWZ1bCAgdG8NCj5oYXZlICBhICBydW5uaW5nDQo+UFBD
ICBiYXNlZCAgc3lzdGVtICB0byAgc2FuaXR5ICBjaGVjayAgd2hhdCAgeW91ICBhcmUgIHRyeWlu
ZyAgdG8gIGRvICBvbiAgdGhlDQo+ZW1iZWRkZWQgIHN5c3RlbSAgeW91ICBhcmUgIGRldmVsb3Bp
bmcgIGZvci4NCj5PZiAgY291cmNlICB0aGUgIGNsb3NlciAgaXQgIGlzICB0byAgdGhlICBwbGF0
Zm9ybSAgeW91ICBhcmUgIGRldmVsb3BpbmcgIGZvciAgdGhlDQo+YmV0dGVyLg0KPkkgIHRob3Vn
aHQgIGFib3V0ICBtb2RpZnlpbmcgIFBlYXJQYyAgdG8gIGVtdWxhdGUgIG15ICBoYXJkd2FyZSwg
IGJ1dCAgaXQgIGxvb2tlZA0KPnRvbyAgbXVjaCAgbGlrZSAgd2FyayAgYW5kICBubyAgb25lICB3
YXMgIHBheWluZyAgZm9yICBpdC4gIFRoZSAgaWRlYSAgaXMgIHN0aWxsDQo+c29tZXdoYXQgIGlu
dHJpZ3VpbmcuICBkZXZlbG9waW5nICBmb3IgIGFuICBlbWJlZGRlZCAgc3lzdGVtICBvbiAgYSAg
c29mdHdhcmUNCj5lbXVsYXRvciAgZm9yICB0aGF0ICBzeXN0ZW0uICBZZXMsICBJICBrbm93ICB0
aGF0ICBpcyAgbm90ICBhbiAgbmV3ICBpZGVhLg0KPg0KPg0KPg0KPg0KPk11c3RhZmEgIMOHYXnE
sXIgIHdyb3RlOg0KPg0KPiA+SGkgIGFsbCwNCj4gPg0KPiA+Q2FuICB5b3UgIHByb3ZpZGUgIHNv
bWUgIGluZm9ybWF0aW9uICBhYm91dCAgUG93ZXJQQyAgc2ltdWxhdG9ycz8gIFdoaWNoICBvbmUg
IGlzICBiZXN0PyAgDQo+ID4NCj4gPkJlc3QgIFJlZ2FyZHMNCj4gPg0KPiA+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPkxpbnV4cHBjLWVtYmVkZGVk
ICBtYWlsaW5nICBsaXN0DQo+ID5MaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnDQo+ID5odHRw
czovL296bGFicy5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eHBwYy1lbWJlZGRlZA0KPiA+DQo+
ID4gICAgDQo+ID4NCj4NCj4tLSAgDQo+RGF2ZSAgTHluY2ggICBETEEgIFN5c3RlbXMNCj5Tb2Z0
d2FyZSAgRGV2ZWxvcG1lbnQ6ICAgICAgICAgICAgICBFbWJlZGRlZCAgTGludXgNCj43MTcuNjI3
LjM3NzAgICAgICAgICAgICBkaGxpaUBkbGFzeXMubmV0ICAgICAgICAgICAgICBodHRwOi8vd3d3
LmRsYXN5cy5uZXQNCj5PdmVyICAyNSAgeWVhcnMnICBleHBlcmllbmNlICBpbiAgcGxhdGZvcm1z
LCAgbGFuZ3VhZ2VzLCAgYW5kICB0ZWNobm9sb2dpZXMgIHRvbyAgbnVtZXJvdXMgIHRvICBsaXN0
Lg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
TGludXhwcGMtZW1iZWRkZWQgIG1haWxpbmcgIGxpc3QNCj5MaW51eHBwYy1lbWJlZGRlZEBvemxh
YnMub3JnDQo+aHR0cHM6Ly9vemxhYnMub3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZW1i
ZWRkZWQNCg0KPSAgPSAgPSAgPSAgPSAgPSAgPSAgPSAgPSAgPSAgPSAgPSAgPSAgPSAgPSAgPSAg
PSAgPSAgPSAgPQ0KDQrjgIDjgIDjgIDjgIDjgIDjgIDjgIDjgIDoh7QNCuekvO+8gQ0KDQoNCuOA
gOOAgOOAgOOAgOOAgOOAgOOAgOOAgGplYW53ZWxseQ0K44CA44CA44CA44CA44CA44CA44CA44CA
amVhbndlbGx5QDEyNi5jb20NCuOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgDIwMDYtMDIt
MTgNCg==
^ permalink raw reply
* [PATCH] Fix BCSR_SIZE for MPC834xSYS
From: KRONSTORFER Horst @ 2006-02-18 10:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
hi!
according to the 'MPC8349E MDS Processor Board User Manual Rev. 1.6 12/2005'
(table 3-1, p. 28) the size of the BCSR mapping is 32kb.
Signed-off-by: Horst Kronstorfer <hkronsto@frequentis.com>
arch/ppc/platforms/83xx/mpc834x_sys.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.h
b/arch/ppc/platforms/83xx/mpc
834x_sys.h
index aa86c22..6727bbd 100644
--- a/arch/ppc/platforms/83xx/mpc834x_sys.h
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.h
@@ -23,7 +23,7 @@
#define VIRT_IMMRBAR ((uint)0xfe000000)
#define BCSR_PHYS_ADDR ((uint)0xf8000000)
-#define BCSR_SIZE ((uint)(128 * 1024))
+#define BCSR_SIZE ((uint)(32 * 1024))
#define BCSR_MISC_REG2_OFF 0x07
#define BCSR_MISC_REG2_PORESET 0x01
-h
[-- Attachment #2: Type: text/html, Size: 1620 bytes --]
^ permalink raw reply related
* Re: Instruction Set Simulator
From: David H. Lynch Jr. @ 2006-02-18 8:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <001301c633a5$b4cde290$9e01120a@bilisim.local>
I looked at PearPC running on an X86 and was able to get Debian ppc
Linux installed on it.
I was looking to use it as a pseudo native platform to do crossplatform
development.
The performance was slow. But otherwise it was interesting.
Eventually I bought a powerbook off eBay cheap.
Most of the time I use cross tools, but now and then it is useful to
have a running
PPC based system to sanity check what you are trying to do on the
embedded system you are developing for.
Of cource the closer it is to the platform you are developing for the
better.
I thought about modifying PearPc to emulate my hardware, but it looked
too much like wark and no one was paying for it. The idea is still
somewhat intriguing. developing for an embedded system on a software
emulator for that system. Yes, I know that is not an new idea.
Mustafa Çayır wrote:
>Hi all,
>
>Can you provide some information about PowerPC simulators? Which one is best?
>
>Best Regards
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
^ permalink raw reply
* ppc32: mpc85xx: set pcibios_fixup only #ifdef CONFIG_PCI
From: Dale Farnsworth @ 2006-02-17 23:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
From: Dale Farnsworth <dale@farnsworth.org>
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
arch/ppc/platforms/85xx/mpc85xx_cds_common.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.10/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
===================================================================
--- linux-2.6.10.orig/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
+++ linux-2.6.10/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
@@ -456,9 +456,6 @@ mpc85xx_cds_setup_arch(void)
mtspr(SPRN_DBCR0, (DBCR0_IDM));
mtspr(SPRN_DBSR, 0xffffffff);
#endif
-
- /* VIA IDE configuration */
- ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup;
#ifdef CONFIG_CPM2
cpm2_reset();
@@ -480,6 +477,9 @@ mpc85xx_cds_setup_arch(void)
loops_per_jiffy = freq / HZ;
#ifdef CONFIG_PCI
+ /* VIA IDE configuration */
+ ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup;
+
/* setup PCI host bridges */
mpc85xx_setup_hose();
#endif
^ permalink raw reply
* 2.6.16-rc4: known regressions
From: Adrian Bunk @ 2006-02-17 23:14 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: len.brown, Dmitry Torokhov, linux-acpi, John Stultz, Meelis Roos,
gregkh, Linux Kernel Mailing List, linuxppc-dev, linux-input,
Sanjoy Mahajan
In-Reply-To: <Pine.LNX.4.64.0602171438050.916@g5.osdl.org>
This email lists some known regressions in 2.6.16-rc4 compared to 2.6.15.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you was declared guilty for a breakage or I'm considering you in any
other way possibly involved with one or more of these issues.
Subject : gnome-volume-manager broken on powerpc since 2.6.16-rc1
References : http://bugzilla.kernel.org/show_bug.cgi?id=6021
Submitter : John Stultz <johnstul@us.ibm.com>
Status : still present in -git two days ago
Subject : S3 sleep hangs the second time - 600X
References : http://bugzilla.kernel.org/show_bug.cgi?id=5989
Submitter : Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk>
Status : problematic commit identified,
further discussion is in the bug
Subject : psmouse starts losing sync in 2.6.16-rc2
References : http://lkml.org/lkml/2006/2/5/50
Submitter : Meelis Roos <mroos@linux.ee>
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com>
Status : Dmitry: Working on various manifestations of this one.
At worst we will have to disable resync by default
before 2.6.16 final is out and continue in 2.6.17 cycle.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [PATCH 2.6.16rc2] SBC82xx - replace NR_SIU_INTS with NR_CPM_INTS
From: Paul Gortmaker @ 2006-02-17 19:00 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
The SBC82xx was left out of the removal/replacement of NR_SIU_INTS.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-07 16:22:28.000000000 -0500
@@ -74,7 +74,7 @@
{
unsigned long flags;
- irq_nr -= NR_SIU_INTS;
+ irq_nr -= NR_CPM_INTS;
spin_lock_irqsave(&sbc82xx_i8259_lock, flags);
sbc82xx_i8259_mask |= 1 << irq_nr;
@@ -88,7 +88,7 @@
{
unsigned long flags;
- irq_nr -= NR_SIU_INTS;
+ irq_nr -= NR_CPM_INTS;
spin_lock_irqsave(&sbc82xx_i8259_lock, flags);
sbc82xx_i8259_mask |= 1 << irq_nr;
@@ -100,7 +100,7 @@
{
unsigned long flags;
- irq_nr -= NR_SIU_INTS;
+ irq_nr -= NR_CPM_INTS;
spin_lock_irqsave(&sbc82xx_i8259_lock, flags);
sbc82xx_i8259_mask &= ~(1 << irq_nr);
@@ -142,7 +142,7 @@
return IRQ_HANDLED;
}
}
- __do_IRQ(NR_SIU_INTS + irq, regs);
+ __do_IRQ(NR_CPM_INTS + irq, regs);
return IRQ_HANDLED;
}
@@ -173,7 +173,7 @@
}
/* Set up the interrupt handlers for the i8259 IRQs */
- for (i = NR_SIU_INTS; i < NR_SIU_INTS + 8; i++) {
+ for (i = NR_CPM_INTS; i < NR_CPM_INTS + 8; i++) {
irq_desc[i].handler = &sbc82xx_i8259_ic;
irq_desc[i].status |= IRQ_LEVEL;
}
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-07 14:48:03.000000000 -0500
@@ -24,13 +24,14 @@
#define BOOTROM_RESTART_ADDR ((uint)0x40000104)
-#define SBC82xx_PC_IRQA (NR_SIU_INTS+0)
-#define SBC82xx_PC_IRQB (NR_SIU_INTS+1)
-#define SBC82xx_MPC185_IRQ (NR_SIU_INTS+2)
-#define SBC82xx_ATM_IRQ (NR_SIU_INTS+3)
-#define SBC82xx_PIRQA (NR_SIU_INTS+4)
-#define SBC82xx_PIRQB (NR_SIU_INTS+5)
-#define SBC82xx_PIRQC (NR_SIU_INTS+6)
-#define SBC82xx_PIRQD (NR_SIU_INTS+7)
+#define SBC82xx_PC_IRQA (NR_CPM_INTS+0)
+#define SBC82xx_PC_IRQB (NR_CPM_INTS+1)
+#define SBC82xx_MPC185_IRQ (NR_CPM_INTS+2)
+#define SBC82xx_ATM_IRQ (NR_CPM_INTS+3)
+
+#define SBC82xx_PIRQA (NR_CPM_INTS+4)
+#define SBC82xx_PIRQB (NR_CPM_INTS+5)
+#define SBC82xx_PIRQC (NR_CPM_INTS+6)
+#define SBC82xx_PIRQD (NR_CPM_INTS+7)
#endif /* __PPC_SBC82xx_H__ */
^ permalink raw reply
* Re: scatter/gather DMA and cache coherency
From: Mark A. Greer @ 2006-02-17 18:12 UTC (permalink / raw)
To: Phil Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <kwaccqbwyw.fsf@lamorak.int.avalon.com.au>
Hi Phil,
On Fri, Feb 17, 2006 at 11:52:31AM +1030, Phil Nitschke wrote:
> >>>>> "MAG" == Mark A Greer <mgreer@mvista.com> writes:
<snip>
> MAG> It would have been useful if you had given the actual hardware
> MAG> you're using.
>
> Processor: http://www.artesyncp.com/products/PmPPC7448.html
Okay but since its a ppmc module, the motherboard its installed on would
be useful info too. Don't worry about it now, more for future reference.
> MAG> For the record, don't assume that this is Artesyn's fault.
> MAG> Artesyn says that the erratum workaround is impractical and they
> MAG> may be right. I don't know, I just write software...
>
> I don't know either. I don't have a problem with Artesyn; they've
> always been nice to me ;-) Here's what one of their engineers had to
> say on the topic:
>
> Artesyn> I stated in a previous email that our boards must have the
> Artesyn> CONFIG_NOT_COHERENT_CACHE option turned on. This is because
> Artesyn> or our history with the Discovery family of bridges.
> Artesyn> Initially it was reported that the hardware cache coherency
> Artesyn> (snooping) was known to be not functional. Then at a later
> Artesyn> date when it was supposed to be fixed, we found that it was
> Artesyn> not completely dependable so Artesyn has taken a stance to
> Artesyn> not trust snooping on the Discovery chips and to always use
> Artesyn> software cache coherency methods.
Yep. I didn't mean to implicate Artesyn. Marvell bridges [so far] have
all had problems with coherency so I definitely believe what's written
above.
> >> So if I understand my situation correctly, the device driver must
> >> use software-enforced coherency to avoid data corruption. Is this
> >> correct?
>
> MAG> It looks like Eugene is guiding you on this. Listen to him. I
> MAG> will add that you should align your buffers on cacheline
> MAG> boundaries and make the allocation sizes multiples of the
> MAG> cacheline size otherwise you could have other data sharing the
> MAG> first and/or last cacheline of your buffers and mess up your
> MAG> software cache mgmt.
>
> It might well be that the third party driver isn't enforcing the
> cacheline boundary alignment.
If it isn't, then you have a bug and it will bite you.
> Artesyn tell me that "it is stated in the
> MV64460 Users Manual that when interfacing cache coherent DRAM or
> integrated SRAM, the maximum write burst size must be set to 32 bytes".
Yes, but you [should] have coherency off so this isn't an issue for you.
> So I guess this is that cacheline size?
Correct, the cacheline size of the 7448 is 32 bytes.
> Anyway, we don't see any
> corruption when the DMA buffer size is 32 bytes, but we do see it for 24
> bytes, 36 bytes, etc.
This sounds like what I was referring to. Do you see the problem?
If you have some other data in the same cacheline as your buffers
(or buffer descriptors) then whenever that other data is read/written
you have the potential for it to screw up the manual cache mgmt you
*thought* you did for your buffers/buf desc's.
Mark
^ permalink raw reply
* Re: Instruction Set Simulator
From: Grant Likely @ 2006-02-17 15:22 UTC (permalink / raw)
To: Mustafa Çayır; +Cc: linuxppc-embedded
In-Reply-To: <001301c633a5$b4cde290$9e01120a@bilisim.local>
Take a look at QEMU
g.
On 17-Feb-06, at 2:37 AM, Mustafa =82ay=F5r wrote:
> Hi all,
>
> Can you provide some information about PowerPC simulators? Which =20
> one is best?
>
> Best Regards
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: SMP support for PPC405 on Virtex-II Pro
From: Andrei Konovalov @ 2006-02-17 10:26 UTC (permalink / raw)
To: Eric L; +Cc: linuxppc-embedded
In-Reply-To: <BAY107-F69111A53C2803D9C08539DFFB0@phx.gbl>
Eric L wrote:
> Hi all,
>
> I know MontaVista has commercial kernels for this feature.
I could be missing something, but AFAIK MontaVista doesn't support SMP
for Virtex-II Pro or Virtex-4.
Best regards,
Andrei
> I also know PPC405 doesn't implement cache coherency.
> Anyhow, is there an open kernel that has SMP support for
> PPC405 cores? Does anyone have a suggestions on getting
> dual PPC405 cores to work under Linux other than having two
> copies of kernels running? Thanks plenty!
>
> -Eric
>
> _________________________________________________________________
> Don’t just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Using modem signal in cpm2 uart for MPC8270
From: Mathieu Deschamps @ 2006-02-17 10:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello ppc-embedded folks,
I'am looking for a hint in arch/ppc/cpm2_io/uart.c on enable modem signal
handling on MontaVista Linux 2.4.20. I know it's a bit ancient but some of
you may have a good memory :) I mentionned enabling modem signal because this
file seems to support modem, yet I come to the conclusion it is incomplete.
In void rs_8xx_interrupt function I've noticed it needs 'modem_control'
defined to get the call done and modem lines changed on interrup(1). Also it
needs defined 'notdef' to implement this code(2).
===(1)
#ifdef modem_control
check_modem_status(info);
#endif
===(2)
#ifdef notdef
/* I need to do this for the SCCs, so it is left as a reminder.
*/
static _INLINE_ void check_modem_status(struct async_struct *info)
{
[...]
}
#endif
===
Having this done is not sufficient, a lot of registers defined in
linux/serial_reg.h are reported missing. I have included this file, yet
other functions are missing, struct members also.
Here is compilation output :
===========================
uart.c: In function `check_modem_status':
uart.c:603: warning: implicit declaration of function `serial_in'
uart.c:638: error: structure has no member named `tqueue_hangup'
uart.c:650: warning: implicit declaration of function `serial_out'
uart.c:651: warning: passing arg 1 of `rs_sched_event' from incompatible
pointer type
uart.c: In function `rs_8xx_interrupt':
uart.c:709: warning: passing arg 1 of `check_modem_status' from incompatible
pointer type
uart.c: In function `startup':
uart.c:813: error: structure has no member named `MCR'
uart.c:815: error: structure has no member named `MCR'
uart.c: In function `change_speed':
uart.c:993: error: structure has no member named `IER'
uart.c:995: error: structure has no member named `IER'
uart.c:998: error: structure has no member named `IER'
uart.c:1005: error: structure has no member named `IER'
uart.c:1007: error: structure has no member named `IER'
uart.c: In function `rs_8xx_throttle':
uart.c:1255: error: structure has no member named `MCR'
uart.c:1258: error: structure has no member named `MCR'
uart.c: In function `rs_8xx_unthrottle':
uart.c:1284: error: structure has no member named `MCR'
uart.c:1286: error: structure has no member named `MCR'
uart.c: In function `get_modem_info':
uart.c:1327: error: structure has no member named `MCR'
uart.c: In function `set_modem_info':
uart.c:1358: error: structure has no member named `MCR'
uart.c:1360: error: structure has no member named `MCR'
uart.c:1363: error: structure has no member named `MCR'
uart.c:1365: error: structure has no member named `MCR'
uart.c:1370: error: structure has no member named `MCR'
uart.c:1372: error: structure has no member named `MCR'
uart.c:1375: error: structure has no member named `MCR'
uart.c:1377: error: structure has no member named `MCR'
uart.c:1381: error: structure has no member named `MCR'
uart.c:1381: error: structure has no member named `MCR'
uart.c:1398: error: structure has no member named `MCR'
uart.c: In function `begin_break':
uart.c:1417: warning: comparison is always false due to limited range of data
type
uart.c: In function `end_break':
uart.c:1461: warning: comparison is always false due to limited range of data
type
uart.c: In function `rs_8xx_ioctl':
uart.c:1600: error: `cprev' undeclared (first use in this function)
uart.c:1600: error: (Each undeclared identifier is reported only once
uart.c:1600: error: for each function it appears in.)
uart.c:1603: error: structure has no member named `delta_msr_wait'
uart.c: In function `rs_8xx_set_termios':
uart.c:1670: error: structure has no member named `MCR'
uart.c:1672: error: structure has no member named `MCR'
uart.c:1679: error: structure has no member named `MCR'
uart.c:1682: error: structure has no member named `MCR'
uart.c:1685: error: structure has no member named `MCR'
uart.c: In function `rs_8xx_wait_until_sent':
uart.c:1839: warning: unused variable `lsr'
=======
I wonder if modem support is incomplete or even if it was dropped in here but
was conceived for another arch .
Looking forward to read your inputs.
Best regards,
Mathieu Deschamps
^ permalink raw reply
* Instruction Set Simulator
From: Mustafa Çayır @ 2006-02-17 9:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Can you provide some information about PowerPC simulators? Which one is =
best?=20
Best Regards
^ permalink raw reply
* Re: scatter/gather DMA and cache coherency
From: Phil Nitschke @ 2006-02-17 1:22 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20060216174655.GC16848@mag.az.mvista.com>
>>>>> "MAG" == Mark A Greer <mgreer@mvista.com> writes:
MAG> On Thu, Feb 16, 2006 at 05:51:20PM +1030, Phil Nitschke wrote:
>> The problem is, that sometimes the data is corrupt (usually on the
>> first transfer). We've concluded that the problem is related to
>> cache coherency. The Artesyn 2.6.10 reference kernel (branched
>> from the kernel at penguinppc.org) must be built with
>> CONFIG_NOT_COHERENT_CACHE=y, as Artesyn have never successfully
>> verified operation with hardware coherency enabled. My
>> understanding is that their Marvel system controller (MV64460)
>> supports cache snooping, but their Linux kernel support hasn't
>> caught up yet.
MAG> It would have been useful if you had given the actual hardware
MAG> you're using.
Processor: http://www.artesyncp.com/products/PmPPC7448.html
MAG> For the record, don't assume that this is Artesyn's fault.
MAG> Artesyn says that the erratum workaround is impractical and they
MAG> may be right. I don't know, I just write software...
I don't know either. I don't have a problem with Artesyn; they've
always been nice to me ;-) Here's what one of their engineers had to
say on the topic:
Artesyn> I stated in a previous email that our boards must have the
Artesyn> CONFIG_NOT_COHERENT_CACHE option turned on. This is because
Artesyn> or our history with the Discovery family of bridges.
Artesyn> Initially it was reported that the hardware cache coherency
Artesyn> (snooping) was known to be not functional. Then at a later
Artesyn> date when it was supposed to be fixed, we found that it was
Artesyn> not completely dependable so Artesyn has taken a stance to
Artesyn> not trust snooping on the Discovery chips and to always use
Artesyn> software cache coherency methods.
>> So if I understand my situation correctly, the device driver must
>> use software-enforced coherency to avoid data corruption. Is this
>> correct?
MAG> It looks like Eugene is guiding you on this. Listen to him. I
MAG> will add that you should align your buffers on cacheline
MAG> boundaries and make the allocation sizes multiples of the
MAG> cacheline size otherwise you could have other data sharing the
MAG> first and/or last cacheline of your buffers and mess up your
MAG> software cache mgmt.
It might well be that the third party driver isn't enforcing the
cacheline boundary alignment. Artesyn tell me that "it is stated in the
MV64460 Users Manual that when interfacing cache coherent DRAM or
integrated SRAM, the maximum write burst size must be set to 32 bytes".
So I guess this is that cacheline size? Anyway, we don't see any
corruption when the DMA buffer size is 32 bytes, but we do see it for 24
bytes, 36 bytes, etc.
I'll discuss this with the H/W vendors that wrote the driver.
--
Phil
^ permalink raw reply
* Re: How to access uboot environment variables from Linux?
From: Wolfgang Denk @ 2006-02-16 23:53 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-dev
In-Reply-To: <F795765B112E7344AF36AA9112796415019ECCF1@xmb-sjc-212.amer.cisco.com>
In message <F795765B112E7344AF36AA9112796415019ECCF1@xmb-sjc-212.amer.cisco.com> you wrote:
>
> How could I access the uboot environment variables from Linux? For
This question is off topic here; you should ask such stuff on the
u-boot-uswers mailing list instead.
> example I would like to access the "serverip"
> and change that to a different ip address during run time.
You should also read the FAQ's before posting. See here:
http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux
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
Our business is run on trust. We trust you will pay in advance.
^ permalink raw reply
* SMP support for PPC405 on Virtex-II Pro
From: Eric L @ 2006-02-16 22:56 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I know MontaVista has commercial kernels for this feature.
I also know PPC405 doesn't implement cache coherency.
Anyhow, is there an open kernel that has SMP support for
PPC405 cores? Does anyone have a suggestions on getting
dual PPC405 cores to work under Linux other than having two
copies of kernels running? Thanks plenty!
-Eric
_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
^ permalink raw reply
* Re: scatter/gather DMA and cache coherency
From: Eugene Surovegin @ 2006-02-16 22:52 UTC (permalink / raw)
To: Phil Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <kw3bijdjzt.fsf@lamorak.int.avalon.com.au>
On Fri, Feb 17, 2006 at 08:49:50AM +1030, Phil Nitschke wrote:
> >>>>> "GB" == Buhler, Greg <greg.buhler@viasat.com> writes:
>
> GB> Phil, If the third party DMA driver is not proprietary send it
> GB> over and I'd be happy to take a look at it for you.
>
> I don't think I can, due to this in the code:
>
> ========================================================================
> /*
> Copyright Notice:
> This computer software is proprietary to VMETRO. The use of this software
> is governed by a licensing agreement. VMETRO retains all rights under
> the copyright laws of the United States of America and other countries.
> This software may not be furnished or disclosed to any third party and
> may not be copied or reproduced by any means, electronic, mechanical, or
> otherwise, in whole or in part, without specific authorization in writing
> from VMETRO.
>
> Copyright (c) 1996-2005 by VMETRO, ASA. All Rights Reserved.
> */
>
> [snip]
>
> /* Set the right GPL license to avoid warrnings then loading the driver */
> MODULE_LICENSE("GPL");
> ========================================================================
>
I'm not a lawyer, but what they are doing is of questionable legality
at least, they circumvent Linux protection but claiming that module is
GPL, but that copyright notice isn't GPL compatible.
If you are going to sell systems with this module, you may have
trouble with your customers, because you'll clearly be violating GPL.
My experience with such vendors - their code isn't worth the trouble
(I have yet to see good Linux driver written by hw vendor) and I'd
rather avoid them completely.
--
Eugene
^ permalink raw reply
* Re: scatter/gather DMA and cache coherency
From: Phil Nitschke @ 2006-02-16 22:19 UTC (permalink / raw)
To: Buhler, Greg; +Cc: linuxppc-embedded
In-Reply-To: <68997D3094017740BB875EB2A425A6EA02E46197@VCAEXCH01.hq.corp.viasat.com>
>>>>> "GB" == Buhler, Greg <greg.buhler@viasat.com> writes:
GB> Phil, If the third party DMA driver is not proprietary send it
GB> over and I'd be happy to take a look at it for you.
I don't think I can, due to this in the code:
========================================================================
/*
Copyright Notice:
This computer software is proprietary to VMETRO. The use of this software
is governed by a licensing agreement. VMETRO retains all rights under
the copyright laws of the United States of America and other countries.
This software may not be furnished or disclosed to any third party and
may not be copied or reproduced by any means, electronic, mechanical, or
otherwise, in whole or in part, without specific authorization in writing
from VMETRO.
Copyright (c) 1996-2005 by VMETRO, ASA. All Rights Reserved.
*/
[snip]
/* Set the right GPL license to avoid warrnings then loading the driver */
MODULE_LICENSE("GPL");
========================================================================
Can you have a GPL driver where the source is copyright?
Thanks for the offer, Greg.
--
Phil
^ permalink raw reply
* [PATCH 2.6.16rc2] EST8260 has bogus bd_info
From: Paul Gortmaker @ 2006-02-16 19:14 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
I managed to rescue an old EST8260 board from a life as a doorstop, and
after sticking u-boot on it, I was getting nothing but a silent death.
I eventually discovered it wouldn't boot because est8260.h had its own
personal copy of an ancient bd_info struct that doesn't match any U-boot
from this century.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
--- linux-2.6.16rc2-orig/arch/ppc/platforms/est8260.h 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/est8260.h 2006-02-16 12:04:02.000000000 -0500
@@ -6,30 +6,15 @@
#ifndef __EST8260_PLATFORM
#define __EST8260_PLATFORM
+#include <linux/config.h>
+#include <asm/ppcboot.h>
+
#define CPM_MAP_ADDR ((uint)0xf0000000)
#define BOOTROM_RESTART_ADDR ((uint)0xff000104)
/* For our show_cpuinfo hooks. */
-#define CPUINFO_VENDOR "EST Corporation"
-#define CPUINFO_MACHINE "SBC8260 PowerPC"
-
-/* A Board Information structure that is given to a program when
- * prom starts it up.
- */
-typedef struct bd_info {
- unsigned int bi_memstart; /* Memory start address */
- unsigned int bi_memsize; /* Memory (end) size in bytes */
- unsigned int bi_intfreq; /* Internal Freq, in Hz */
- unsigned int bi_busfreq; /* Bus Freq, in MHz */
- unsigned int bi_cpmfreq; /* CPM Freq, in MHz */
- unsigned int bi_brgfreq; /* BRG Freq, in MHz */
- unsigned int bi_vco; /* VCO Out from PLL */
- unsigned int bi_baudrate; /* Default console baud rate */
- unsigned int bi_immr; /* IMMR when called from boot rom */
- unsigned char bi_enetaddr[6];
-} bd_t;
-
-extern bd_t m8xx_board_info;
+#define CPUINFO_VENDOR "Wind River"
+#define CPUINFO_MACHINE "EST SBC8260 PowerPC"
#endif /* __EST8260_PLATFORM */
^ permalink raw reply
* PEMICRO CABLEPPC and GDB
From: dibacco @ 2006-02-16 19:22 UTC (permalink / raw)
To: linuxppc-embedded
I have bought a P&E MICRO CABLEPPC (parallel bdm wiggler). Someone was su=
ccessful using it with Linux? Is there a driver for linux?
Bye,
Antonio.
^ permalink raw reply
* module_init macro seems not to work
From: dibacco @ 2006-02-16 19:20 UTC (permalink / raw)
To: linuxppc-embedded
If I use something like:
module_init(cpm_timer_init);
cpm_timer_init is not called when I load the module.
I have to call cpm_timer_init inside init_module() .
Bye,
Antonio.
^ 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