Menu
▾
▴
linuxsh-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(82) |
Jun
(72) |
Jul
(39) |
Aug
(104) |
Sep
(61) |
Oct
(55) |
Nov
(101) |
Dec
(48) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(52) |
Feb
(67) |
Mar
(18) |
Apr
(16) |
May
(33) |
Jun
(12) |
Jul
(102) |
Aug
(168) |
Sep
(65) |
Oct
(60) |
Nov
(43) |
Dec
(121) |
| 2002 |
Jan
(69) |
Feb
(32) |
Mar
(90) |
Apr
(59) |
May
(45) |
Jun
(43) |
Jul
(33) |
Aug
(21) |
Sep
(11) |
Oct
(20) |
Nov
(26) |
Dec
(3) |
| 2003 |
Jan
(12) |
Feb
(18) |
Mar
(11) |
Apr
(11) |
May
(41) |
Jun
(76) |
Jul
(77) |
Aug
(15) |
Sep
(38) |
Oct
(56) |
Nov
(19) |
Dec
(39) |
| 2004 |
Jan
(17) |
Feb
(52) |
Mar
(36) |
Apr
(34) |
May
(48) |
Jun
(85) |
Jul
(38) |
Aug
(42) |
Sep
(41) |
Oct
(77) |
Nov
(27) |
Dec
(19) |
| 2005 |
Jan
(32) |
Feb
(35) |
Mar
(29) |
Apr
(8) |
May
(7) |
Jun
(31) |
Jul
(46) |
Aug
(93) |
Sep
(65) |
Oct
(85) |
Nov
(219) |
Dec
(47) |
| 2006 |
Jan
(170) |
Feb
(103) |
Mar
(49) |
Apr
(43) |
May
(45) |
Jun
(29) |
Jul
(77) |
Aug
(82) |
Sep
(43) |
Oct
(45) |
Nov
(26) |
Dec
(85) |
| 2007 |
Jan
(42) |
Feb
(48) |
Mar
(64) |
Apr
(31) |
May
(88) |
Jun
(53) |
Jul
(175) |
Aug
(212) |
Sep
(91) |
Oct
(103) |
Nov
(110) |
Dec
(5) |
| 2008 |
Jan
(20) |
Feb
(11) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(3) |
Oct
(12) |
Nov
|
Dec
|
|
From: SUGIOKA T. <su...@it...> - 2003-06-20 03:27:10
|
At 22:50 03/06/19 -0400, Daniel Jacobowitz <dr...@fa...> wrote: >Has Toshinobu-san's patch been applied (where)? Yes, corresponding ChangeLog entry in "linux-2_4-branch" branch is 2003-02-13 SUGIOKA Toshinobu <su...@it...> * arch/sh/kernel/entry.S: Call sys_pread_wrapper/sys_pwrite_wrapper instead of sys_pread/sys_pwrite. * arch/sh/kernel/sys_sh.c (sys_pread_wrapper,sys_pwrite_wrapper): New function. This was also applied to HEAD. Currently, pread/pwrite takes 6 arguments like MIPS. ---- SUGIOKA Toshinobu |
|
From: Daniel J. <dr...@fa...> - 2003-06-20 02:52:28
|
On Fri, Jun 20, 2003 at 10:43:33AM +0900, kaz Kojima wrote: > Daniel Jacobowitz <dr...@fa...> wrote: > > I believe this flushes my current patches to make glibc work on SH. Issues: > > - MIPS pread functions have some wackiness in them for the MIPS calling > > conventions, which align long longs to even register pairs; it appears > > that SH does not do this. This fixes pread64/pwrite64. > > - st_ino is _NOT_ 64-bit in the latest SH kernel trees, or at least it > > wasn't when I checked in April. --enable-kernel=2.4.x breaks terribly > > without this patch; the errors are along the lines of "version GLIBC_2.3 > > not found", because that's the first consequence of a messed up inode > > field - ld.so compares by inodes at some point. > [snip] > > 2003-06-19 Daniel Jacobowitz <dr...@mv...> > > > > * sysdeps/unix/sysv/linux/kernel-features.h: Update kernel features > > for the SH architecture. > > I agree with this one. About pread64/pwrite64, did you see the argument > in the another list > <URL:http://www.geocrawler.com/mail/msg.php3?msg_id=10038494&list=3076>? Sorry, too many lists - I'm not on linuxsh-dev. I admit I only tested SH-3, though. So I guess that patch would break SH-4? Has Toshinobu-san's patch been applied (where)? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer |
|
From: kaz K. <kk...@rr...> - 2003-06-20 01:32:05
|
Daniel Jacobowitz <dr...@fa...> wrote: > I believe this flushes my current patches to make glibc work on SH. Issues: > - MIPS pread functions have some wackiness in them for the MIPS calling > conventions, which align long longs to even register pairs; it appears > that SH does not do this. This fixes pread64/pwrite64. > - st_ino is _NOT_ 64-bit in the latest SH kernel trees, or at least it > wasn't when I checked in April. --enable-kernel=2.4.x breaks terribly > without this patch; the errors are along the lines of "version GLIBC_2.3 > not found", because that's the first consequence of a messed up inode > field - ld.so compares by inodes at some point. [snip] > 2003-06-19 Daniel Jacobowitz <dr...@mv...> > > * sysdeps/unix/sysv/linux/kernel-features.h: Update kernel features > for the SH architecture. I agree with this one. About pread64/pwrite64, did you see the argument in the another list <URL:http://www.geocrawler.com/mail/msg.php3?msg_id=10038494&list=3076>? Regards, kaz |
|
From: Paul M. <le...@li...> - 2003-06-19 19:27:13
|
On Thu, Jun 19, 2003 at 06:13:21PM +0100, Alex Bennee wrote: > The patch shouldn't break anything outside of the drop-in tree as the > original STB1 #define is still available (unless of course you select > the GX1 processor). >=20 I'm a bit curious as to what the differences between the ST40STB1 and the G= X1 are. Namely, are there any cache changes? (This would be nice to know before merging the 2.5 backport of the cache changes). Also, are there documented differences for what we can expect for PVR and P= RR values for STB1 and GX1? (Well, we have the STB1 values, really just the GX1 ones would be nice). > It would help to know so I can set my CVS gingerness level for changing > ST40 related stuff. There are a lot of patches in the ST tree that > really could do with being ported into the linuxsh CVS. I'll be focusing > on the 2.4 tree as I currently don't have time to also track the 2.5 > tree. >=20 I'd also be interested in knowing who else is using the st40 stuff, since there's quite a bit of 2.5 stuff that needs fixing and testing in order to = work on the st40 properly! > +if [ "$CONFIG_CPU_SUBTYPE_ST40" =3D "y" ]; then > + bool 'PCI emulation of on-chip peripherals' CONFIG_SH_PCI_EMULATION > + if [ "$CONFIG_SH_PCI_EMULATION" =3D "y" -a > "$CONFIG_CPU_SUBTYPE_ST40GX1" =3D "y" ]; then > + bool ' USB OHCI Host Controller' CONFIG_SH_PCI_USB > + fi > +fi > =20 Are there any other users of the CONFIG_SH_PCI_EMULATION? If not, why not just have a: =09 dep_bool ' USB OHCI Host Controller' CONFIG_SH_PCI_USB $CONFIG_CPU_SUBTYP= E_ST40GX1 and leave this option out entirely? > bool 'PCI support' CONFIG_PCI > if [ "$CONFIG_PCI" =3D "y" ]; then > - bool 'Cache and PCI noncoherent' CONFIG_SH_PCIDMA_NONCOHERENT > + choice ' PCI access mode' \ > + "BIOS CONFIG_PCI_GOBIOS \ > + Direct CONFIG_PCI_GODIRECT \ > + Any CONFIG_PCI_GOANY" Any > + if [ "$CONFIG_PCI_GOBIOS" =3D "y" -o "$CONFIG_PCI_GOANY" =3D "y" ]; t= hen > + define_bool CONFIG_PCI_BIOS y > + fi > + if [ "$CONFIG_PCI_GODIRECT" =3D "y" -o "$CONFIG_PCI_GOANY" =3D "y" ]; > then > + define_bool CONFIG_PCI_DIRECT y > + fi > + if [ "$CONFIG_CPU_SUBTYPE_ST40" =3D "y" ]; then > + define_bool CONFIG_SH_PCIDMA_NONCOHERENT y > + else > + define_bool CONFIG_SH_PCIDMA_NONCOHERENT n > + fi > fi > =20 Watch it, this undoes the changes dwmw2 did yesterday to back out the GOBIOS/GODIRECT/GOANY stuff. See the "problems with PCI on SH7751 board" thread. CONFIG_SH_PCIDMA_NONCOHERENT should also remain an option (not a forced one= ), since it especially helps with debugging even on boards that don't need it! > diff -u -r1.1.1.1.2.4 time.c > --- arch/sh/kernel/time.c 10 Jun 2002 06:22:45 -0000 1.1.1.1.2.4 > +++ arch/sh/kernel/time.c 19 Jun 2003 16:42:49 -0000 > @@ -78,10 +78,10 @@ > #define CCN_PVR_CHIP_MASK 0xff > #define CCN_PVR_CHIP_ST40STB1 0x4 > =20 Nothing for the GX1? [snip the rest] The rest looks good. |
|
From: Alex B. <ker...@be...> - 2003-06-19 17:13:41
|
Hi,
I now have write access to CVS and I want to bring the ST40 bits and
pieces a little more into line with the latest ST40 stuff that Stuart
has. The first trivial change is to make all the generic ST40 code use
the CONFIG_CPU_SUBTYPE_ST40 instead of the STB1 which is only one of the
varients. Apart from aesthetic reasons it also makes syncing with the ST
kernel tree a lot easier.
The patch shouldn't break anything outside of the drop-in tree as the
original STB1 #define is still available (unless of course you select
the GX1 processor).
Who else on the list is actually using the ST40 or varients apart from
myself and Stuart?
It would help to know so I can set my CVS gingerness level for changing
ST40 related stuff. There are a lot of patches in the ST tree that
really could do with being ported into the linuxsh CVS. I'll be focusing
on the 2.4 tree as I currently don't have time to also track the 2.5
tree.
I'll commit these changes tommorow unless there is a storm of protest
:-)
Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/linux/ChangeLog,v
retrieving revision 1.1.1.1.2.72
diff -u -r1.1.1.1.2.72 ChangeLog
--- ChangeLog 19 Jun 2003 08:06:56 -0000 1.1.1.1.2.72
+++ ChangeLog 19 Jun 2003 16:41:57 -0000
@@ -1,3 +1,7 @@
+2003-06-19 Alex Bennee <ker...@be...>
+ * Changed CPU type CPU_ST40STB1 to CPU_ST40
+ * Made all generic ST40 code use CONFIG_CPU_SUBTYPE_ST40
+
2003-06-19 David Woodhouse <dw...@re...>
* include/asm-sh/parport.h: New file to allow use of PC-style
Index: Documentation/Configure.help
===================================================================
RCS file: /cvsroot/linuxsh/linux/Documentation/Attic/Configure.help,v
retrieving revision 1.1.1.1.2.11
diff -u -r1.1.1.1.2.11 Configure.help
--- Documentation/Configure.help 29 May 2003 04:21:27 -0000 1.1.1.1.2.11
+++ Documentation/Configure.help 19 Jun 2003 16:42:45 -0000
@@ -26270,7 +26270,10 @@
Select SH7751 if you have a SH7751
- Select ST40STB1 if you have a ST40STB1
+ Select ST40RA/ST40STB1 if you have a ST40RA
+ (previously known as ST40STB1).
+
+ Select ST40GX1 if you have an ST40GX1.
SH7708
CONFIG_CPU_SUBTYPE_SH7708
@@ -26289,9 +26292,26 @@
CONFIG_CPU_SUBTYPE_SH7751
Select SH7750 if you have a 166 Mhz SH-4 HD6417751 CPU.
-ST40STB1
+ST40RA/ST40STB1
CONFIG_CPU_SUBTYPE_ST40STB1
- Select ST40STB1 if you have a ST40STB1 CPU.
+ Select ST40RA/ST40STB1 if you have a ST40RA. This chip was
+ previously called the ST40STB1. Early versions were also
+ erronously labelled ST40AR166.
+
+ST40GX1
+CONFIG_CPU_SUBTYPE_ST40GX1
+ Select ST40GX1 if you have a ST40GX1 CPU.
+
+Memory on LMI
+CONFIG_ST40_LMI_MEMORY
+ Currently all ST40 CPUs have two external buses the
+ 'Local Memory Interface' (LMI) which supports SDRAM and
+ DDR SDRAM, and the 'Enhanced flash Memory Interface' (EMI),
+ which supports SDRAM, Flash, peripherials and MPX. Linux
+ can support memory on either of these buses, it is simply
+ necessary to specify its base address. This option is simply
+ a shortcut method of specifying that RAM starts from the
+ bottom of the LMI.
Physical memory start address
CONFIG_MEMORY_START
Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/Attic/config.in,v
retrieving revision 1.1.1.1.2.10
diff -u -r1.1.1.1.2.10 config.in
--- arch/sh/config.in 18 Jun 2003 16:24:41 -0000 1.1.1.1.2.10
+++ arch/sh/config.in 19 Jun 2003 16:42:45 -0000
@@ -65,7 +65,8 @@
SH7709 CONFIG_CPU_SUBTYPE_SH7709 \
SH7750 CONFIG_CPU_SUBTYPE_SH7750 \
SH7751 CONFIG_CPU_SUBTYPE_SH7751 \
- ST40STB1 CONFIG_CPU_SUBTYPE_ST40STB1" SH7708
+ ST40RA/ST40STB1 CONFIG_CPU_SUBTYPE_ST40STB1 \
+ ST40GX1 CONFIG_CPU_SUBTYPE_ST40GX1" SH7708
if [ "$CONFIG_CPU_SUBTYPE_SH7707" = "y" ]; then
define_bool CONFIG_CPU_SH3 y
define_bool CONFIG_CPU_SH4 n
@@ -89,6 +90,12 @@
if [ "$CONFIG_CPU_SUBTYPE_ST40STB1" = "y" ]; then
define_bool CONFIG_CPU_SH3 n
define_bool CONFIG_CPU_SH4 y
+ define_bool CONFIG_CPU_SUBTYPE_ST40 y
+fi
+if [ "$CONFIG_CPU_SUBTYPE_ST40GX1" = "y" ]; then
+ define_bool CONFIG_CPU_SH3 n
+ define_bool CONFIG_CPU_SH4 y
+ define_bool CONFIG_CPU_SUBTYPE_ST40 y
fi
bool 'Little Endian' CONFIG_CPU_LITTLE_ENDIAN
# Platform-specific memory start and size definitions
@@ -109,7 +116,7 @@
define_hex CONFIG_MEMORY_SIZE 00400000
define_bool CONFIG_MEMORY_SET y
fi
-if [ "$CONFIG_CPU_SUBTYPE_ST40STB1" = "y" ]; then
+if [ "$CONFIG_CPU_SUBTYPE_ST40" = "y" ]; then
bool 'Memory on LMI' CONFIG_ST40_LMI_MEMORY
if [ "$CONFIG_ST40_LMI_MEMORY" = "y" ] ; then
define_hex CONFIG_MEMORY_START 08000000
@@ -133,6 +140,13 @@
hex 'Physical memory size' CONFIG_MEMORY_SIZE 00400000
fi
dep_bool 'Enable OC RAM zone (experimental)' CONFIG_SCRATCH_SPACE
$CONFIG_EXPERIMENTAL
+
+if [ "$CONFIG_CPU_SUBTYPE_ST40" = "y" ]; then
+ bool 'PCI emulation of on-chip peripherals' CONFIG_SH_PCI_EMULATION
+ if [ "$CONFIG_SH_PCI_EMULATION" = "y" -a
"$CONFIG_CPU_SUBTYPE_ST40GX1" = "y" ]; then
+ bool ' USB OHCI Host Controller' CONFIG_SH_PCI_USB
+ fi
+fi
endmenu
if [ "$CONFIG_SH_HP690" = "y" ]; then
@@ -199,7 +213,21 @@
bool 'PCI support' CONFIG_PCI
if [ "$CONFIG_PCI" = "y" ]; then
- bool 'Cache and PCI noncoherent' CONFIG_SH_PCIDMA_NONCOHERENT
+ choice ' PCI access mode' \
+ "BIOS CONFIG_PCI_GOBIOS \
+ Direct CONFIG_PCI_GODIRECT \
+ Any CONFIG_PCI_GOANY" Any
+ if [ "$CONFIG_PCI_GOBIOS" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
+ define_bool CONFIG_PCI_BIOS y
+ fi
+ if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ];
then
+ define_bool CONFIG_PCI_DIRECT y
+ fi
+ if [ "$CONFIG_CPU_SUBTYPE_ST40" = "y" ]; then
+ define_bool CONFIG_SH_PCIDMA_NONCOHERENT y
+ else
+ define_bool CONFIG_SH_PCIDMA_NONCOHERENT n
+ fi
fi
source drivers/pci/Config.in
Index: arch/sh/kernel/Makefile
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/Makefile,v
retrieving revision 1.1.1.1.2.6
diff -u -r1.1.1.1.2.6 Makefile
--- arch/sh/kernel/Makefile 13 Jun 2003 23:25:31 -0000 1.1.1.1.2.6
+++ arch/sh/kernel/Makefile 19 Jun 2003 16:42:45 -0000
@@ -31,7 +31,7 @@
obj-y += pci-dc.o pcibios.o
else
obj-y += pci-dma.o pcibios.o
-obj-$(CONFIG_CPU_SUBTYPE_ST40STB1)+= pci_st40.o
+obj-$(CONFIG_CPU_SUBTYPE_ST40)+= pci_st40.o
obj-$(CONFIG_CPU_SUBTYPE_SH7751)+= pci-sh7751.o
obj-$(CONFIG_SH_BIGSUR)+= pci-bigsur.o
obj-$(CONFIG_SH_7751_SOLUTION_ENGINE)+= pci-7751se.o
@@ -69,7 +69,7 @@
obj-$(CONFIG_HD64461) += setup_hd64461.o io_hd64461.o
machine-specific-objs += setup_hd64461.o io_hd64461.o
-obj-$(CONFIG_CPU_SUBTYPE_ST40STB1) +=irq_intc2.o
+obj-$(CONFIG_CPU_SUBTYPE_ST40) +=irq_intc2.o
obj-$(CONFIG_SH_ADX) += mach_adx.o setup_adx.o io_adx.o irq_maskreg.o
machine-specific-objs += mach_adx.o setup_adx.o io_adx.o irq_maskreg.o
Index: arch/sh/kernel/entry.S
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/entry.S,v
retrieving revision 1.1.1.1.2.13
diff -u -r1.1.1.1.2.13 entry.S
--- arch/sh/kernel/entry.S 13 Feb 2003 01:12:06 -0000 1.1.1.1.2.13
+++ arch/sh/kernel/entry.S 19 Jun 2003 16:42:48 -0000
@@ -869,7 +869,7 @@
.long SYMBOL_NAME(do_IRQ) ! pwon
.long SYMBOL_NAME(do_IRQ) ! pwdwn
.long SYMBOL_NAME(do_IRQ) ! err
-#elif defined(CONFIG_CPU_SUBTYPE_ST40STB1)
+#elif defined(CONFIG_CPU_SUBTYPE_ST40)
.long error ! 50 0x840
.long error ! 51 0x860
.long error ! 52 0x880
@@ -901,14 +901,14 @@
.long SYMBOL_NAME(do_IRQ) ! 78 0xbc0 DMA ERR
.long error ! 79 0xbe0
.long SYMBOL_NAME(do_IRQ) ! 80 0xc00 PIO0
- .long SYMBOL_NAME(do_IRQ) ! 81 0xc20 PIO1
- .long SYMBOL_NAME(do_IRQ) ! 82 0xc40 PIO2
+ .long error ! 81 0xc20
+ .long error ! 82 0xc40
.long error ! 83 0xc60
- .long error ! 84 0xc80
+ .long SYMBOL_NAME(do_IRQ) ! 84 0xc80 PIO1
.long error ! 85 0xca0
.long error ! 86 0xcc0
.long error ! 87 0xce0
- .long error ! 88 0xd00
+ .long SYMBOL_NAME(do_IRQ) ! 88 0xd00 PIO2
.long error ! 89 0xd20
.long error ! 90 0xd40
.long error ! 91 0xd60
@@ -932,6 +932,7 @@
.long error ! 109 0xfa0
.long error ! 110 0xfc0
.long error ! 111 0xfe0
+# if defined(CONFIG_CPU_SUBTYPE_ST40STB1)
.long SYMBOL_NAME(do_IRQ) ! 112 0x1000 Mailbox
.long error ! 113 0x1020
.long error ! 114 0x1040
@@ -964,6 +965,74 @@
.long error ! 141 0x13a0
.long error ! 142 0x13c0
.long error ! 143 0x13e0
+# elif defined(CONFIG_CPU_SUBTYPE_ST40GX1)
+ .long SYMBOL_NAME(do_IRQ) ! 112 0x1000 Mailbox
+ .long error ! 113 0x1020
+ .long error ! 114 0x1040
+ .long error ! 115 0x1060
+ .long SYMBOL_NAME(do_IRQ) ! 116 0x1080 SSC0
+ .long error ! 117 0x10a0
+ .long error ! 118 0x10c0
+ .long error ! 119 0x10e0
+ .long SYMBOL_NAME(do_IRQ) ! 120 0x1100 IRBlaster IRB
+ .long error ! 121 0x1120
+ .long error ! 122 0x1140
+ .long error ! 123 0x1160
+ .long SYMBOL_NAME(do_IRQ) ! 124 0x1180 USB host
+ .long error ! 125 0x11a0
+ .long error ! 126 0x11c0
+ .long error ! 127 0x11e0
+ .long SYMBOL_NAME(do_IRQ) ! 128 0x1200 Video Processor BLITER
+ .long error ! 129 0x1220
+ .long error ! 130 0x1240
+ .long error ! 131 0x1260
+ .long SYMBOL_NAME(do_IRQ) ! 132 0x1280 UART0 UART0
+ .long error ! 133 0x12a0
+ .long SYMBOL_NAME(do_IRQ) ! 134 0x12c0 UART2
+ .long error ! 135 0x12e0
+ .long SYMBOL_NAME(do_IRQ) ! 136 0x1300 Additional PIO IO_PIO0
+ .long error ! 137 0x1320
+ .long error ! 138 0x1340
+ .long error ! 139 0x1360
+ .long SYMBOL_NAME(do_IRQ) ! 140 0x1380 EMPI INV_ADDR
+ .long error ! 141 0x13a0
+ .long error ! 142 0x13c0
+ .long error ! 143 0x13e0
+ .long SYMBOL_NAME(do_IRQ) ! 144 0x1400 MAFE
+ .long error ! 145 0x1420
+ .long error ! 146 0x1440
+ .long error ! 147 0x1460
+ .long SYMBOL_NAME(do_IRQ) ! 148 0x1480 PWM
+ .long error ! 149 0x14a0
+ .long error ! 150 0x14c0
+ .long error ! 151 0x14e0
+ .long SYMBOL_NAME(do_IRQ) ! 152 0x1500 SSC1
+ .long error ! 153 0x1520
+ .long error ! 154 0x1540
+ .long error ! 155 0x1560
+ .long SYMBOL_NAME(do_IRQ) ! 156 0x1580 Additional PIO IO_PIO1
+ .long error ! 157 0x15a0
+ .long error ! 158 0x15c0
+ .long error ! 159 0x15e0
+ .long SYMBOL_NAME(do_IRQ) ! 160 0x1600 USB target
+ .long error ! 161 0x1620
+ .long error ! 162 0x1640
+ .long error ! 163 0x1660
+ .long SYMBOL_NAME(do_IRQ) ! 164 0x1680 UART1 UART1
+ .long error ! 165 0x16a0
+ .long error ! 166 0x16c0
+ .long error ! 167 0x16e0
+ .long SYMBOL_NAME(do_IRQ) ! 168 0x1700 Teletext TTXT
+ .long error ! 169 0x1720
+ .long error ! 170 0x1740
+ .long error ! 171 0x1760
+ .long SYMBOL_NAME(do_IRQ) ! 172 0x1780 Video Sync VTG
+ .long SYMBOL_NAME(do_IRQ) ! 173 0x17a0 DVP0
+ .long SYMBOL_NAME(do_IRQ) ! 174 0x17c0 DVP1
+ .long error ! 175 0x17e0
+# else
+# error Unknown ST40 type
+# endif
#endif
ENTRY(sys_call_table)
Index: arch/sh/kernel/setup.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/setup.c,v
retrieving revision 1.1.1.1.2.6
diff -u -r1.1.1.1.2.6 setup.c
--- arch/sh/kernel/setup.c 24 Oct 2002 16:21:46 -0000 1.1.1.1.2.6
+++ arch/sh/kernel/setup.c 19 Jun 2003 16:42:49 -0000
@@ -547,7 +547,7 @@
PRINT_CLOCK("CPU", boot_cpu_data.cpu_clock);
PRINT_CLOCK("Bus", boot_cpu_data.bus_clock);
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
PRINT_CLOCK("Memory", boot_cpu_data.memory_clock);
#endif
PRINT_CLOCK("Peripheral module", boot_cpu_data.module_clock);
Index: arch/sh/kernel/time.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/time.c,v
retrieving revision 1.1.1.1.2.4
diff -u -r1.1.1.1.2.4 time.c
--- arch/sh/kernel/time.c 10 Jun 2002 06:22:45 -0000 1.1.1.1.2.4
+++ arch/sh/kernel/time.c 19 Jun 2003 16:42:49 -0000
@@ -78,10 +78,10 @@
#define CCN_PVR_CHIP_MASK 0xff
#define CCN_PVR_CHIP_ST40STB1 0x4
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
#define CLOCKGEN_MEMCLKCR 0xbb040038
#define MEMCLKCR_RATIO_MASK 0x7
-#endif /* CONFIG_CPU_SUBTYPE_ST40STB1 */
+#endif /* CONFIG_CPU_SUBTYPE_ST40 */
#endif /* __sh3__ or __SH4__ */
extern rwlock_t xtime_lock;
@@ -323,7 +323,7 @@
void __init time_init(void)
{
unsigned int cpu_clock, master_clock, bus_clock, module_clock;
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
unsigned int memory_clock;
#endif
unsigned int timer_freq;
@@ -338,7 +338,7 @@
#define bfc_table ifc_table /* Same */
static int pfc_table[] = { 2, 3, 4, 6, 8, 2, 2, 2 };
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
struct frqcr_data {
unsigned short frqcr;
struct {
@@ -419,7 +419,7 @@
}
#elif defined(__SH4__)
{
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
unsigned long pvr;
/* This should probably be moved into the SH3 probing code, and then
use the processor
@@ -473,14 +473,14 @@
master_clock = module_clock * pfc;
bus_clock = master_clock / bfc;
cpu_clock = master_clock / ifc;
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
skip_calc:
#endif
printk("CPU clock: %d.%02dMHz\n",
(cpu_clock / 1000000), (cpu_clock % 1000000)/10000);
printk("Bus clock: %d.%02dMHz\n",
(bus_clock/1000000), (bus_clock % 1000000)/10000);
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
printk("Memory clock: %d.%02dMHz\n",
(memory_clock/1000000), (memory_clock % 1000000)/10000);
#endif
@@ -493,7 +493,7 @@
current_cpu_data.cpu_clock = cpu_clock;
current_cpu_data.master_clock = master_clock;
current_cpu_data.bus_clock = bus_clock;
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
current_cpu_data.memory_clock = memory_clock;
#endif
current_cpu_data.module_clock = module_clock;
Index: arch/sh/mm/cache-sh4.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/mm/cache-sh4.c,v
retrieving revision 1.1.1.1.2.6
diff -u -r1.1.1.1.2.6 cache-sh4.c
--- arch/sh/mm/cache-sh4.c 10 Jun 2002 06:22:45 -0000 1.1.1.1.2.6
+++ arch/sh/mm/cache-sh4.c 19 Jun 2003 16:42:49 -0000
@@ -56,8 +56,8 @@
static void __init
detect_cpu_and_cache_system(void)
{
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
- cpu_data->type = CPU_ST40STB1;
+#ifdef CONFIG_CPU_SUBTYPE_ST40
+ cpu_data->type = CPU_ST40;
#elif defined(CONFIG_CPU_SUBTYPE_SH7750) ||
defined(CONFIG_CPU_SUBTYPE_SH7751)
cpu_data->type = CPU_SH7750;
#else
@@ -214,7 +214,7 @@
unsigned long flags;
extern void __flush_cache_4096(unsigned long addr, unsigned long phys,
unsigned long exec_offset);
-#if defined(CONFIG_CPU_SUBTYPE_SH7751) ||
defined(CONFIG_CPU_SUBTYPE_ST40STB1)
+#if defined(CONFIG_CPU_SUBTYPE_SH7751) ||
defined(CONFIG_CPU_SUBTYPE_ST40)
if (start >= CACHE_OC_ADDRESS_ARRAY) {
/*
* SH7751 and ST40 have no restriction to handle cache.
Index: drivers/char/sh-sci.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/drivers/char/sh-sci.c,v
retrieving revision 1.1.1.1.2.5
diff -u -r1.1.1.1.2.5 sh-sci.c
--- drivers/char/sh-sci.c 23 Oct 2002 00:57:46 -0000 1.1.1.1.2.5
+++ drivers/char/sh-sci.c 19 Jun 2003 16:42:52 -0000
@@ -806,7 +806,7 @@
}
break_continue:
-#if defined(CONFIG_CPU_SUBTYPE_SH7750) ||
defined(CONFIG_CPU_SUBTYPE_ST40STB1)
+#if defined(CONFIG_CPU_SUBTYPE_SH7750) ||
defined(CONFIG_CPU_SUBTYPE_ST40)
/* XXX: Handle SCIF overrun error */
if (port->type == PORT_SCIF && (sci_in(port, SCLSR) & SCIF_ORER) != 0)
{
sci_out(port, SCLSR, 0);
Index: drivers/char/sh-sci.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/drivers/char/sh-sci.h,v
retrieving revision 1.1.1.1.2.1
diff -u -r1.1.1.1.2.1 sh-sci.h
--- drivers/char/sh-sci.h 10 May 2002 17:58:55 -0000 1.1.1.1.2.1
+++ drivers/char/sh-sci.h 19 Jun 2003 16:42:52 -0000
@@ -59,7 +59,7 @@
0x30 /* TIE=0,RIE=0,TE=1,RE=1 */ : \
0x38 /* TIE=0,RIE=0,TE=1,RE=1,REIE=1 */ )
# define SCI_AND_SCIF
-#elif defined(CONFIG_CPU_SUBTYPE_ST40STB1)
+#elif defined(CONFIG_CPU_SUBTYPE_ST40)
# define SCI_NPORTS 2
# define SCI_INIT { \
{ {}, PORT_SCIF, 0xffe00000, STB1_SCIF1_IRQS, sci_init_pins_scif }, \
@@ -308,7 +308,7 @@
#endif
return 1;
}
-#elif defined(CONFIG_CPU_SUBTYPE_ST40STB1)
+#elif defined(CONFIG_CPU_SUBTYPE_ST40)
static inline int sci_rxd_in(struct sci_port *port)
{
if (port->base == 0xffe00000)
Index: include/asm-sh/bugs.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/bugs.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 bugs.h
--- include/asm-sh/bugs.h 15 Oct 2001 20:45:06 -0000 1.1.1.1
+++ include/asm-sh/bugs.h 19 Jun 2003 16:42:52 -0000
@@ -34,9 +34,9 @@
*p++ = '4';
printk("CPU: SH7750/SH7751\n");
break;
- case CPU_ST40STB1:
+ case CPU_ST40:
*p++ = '4';
- printk("CPU: ST40STB1\n");
+ printk("CPU: ST40STB1/GX1\n");
break;
default:
printk("CPU: ??????\n");
Index: include/asm-sh/irq.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/irq.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 irq.h
--- include/asm-sh/irq.h 15 Oct 2001 20:45:09 -0000 1.1.1.1
+++ include/asm-sh/irq.h 19 Jun 2003 16:42:53 -0000
@@ -80,7 +80,7 @@
#define IRDA_IPR_POS 2
#define IRDA_PRIORITY 3
#elif defined(CONFIG_CPU_SUBTYPE_SH7750) ||
defined(CONFIG_CPU_SUBTYPE_SH7751) || \
- defined(CONFIG_CPU_SUBTYPE_ST40STB1)
+ defined(CONFIG_CPU_SUBTYPE_ST40)
#define SCIF_ERI_IRQ 40
#define SCIF_RXI_IRQ 41
#define SCIF_BRI_IRQ 42
@@ -88,7 +88,7 @@
#define SCIF_IPR_ADDR INTC_IPRC
#define SCIF_IPR_POS 1
#define SCIF_PRIORITY 3
-#if defined(CONFIG_CPU_SUBTYPE_ST40STB1)
+#if defined(CONFIG_CPU_SUBTYPE_ST40)
#define SCIF1_ERI_IRQ 23
#define SCIF1_RXI_IRQ 24
#define SCIF1_BRI_IRQ 25
@@ -123,6 +123,10 @@
# define ONCHIP_NR_IRQS 72
# elif defined(CONFIG_CPU_SUBTYPE_ST40STB1)
# define ONCHIP_NR_IRQS 144
+# elif defined(CONFIG_CPU_SUBTYPE_ST40GX1)
+# define ONCHIP_NR_IRQS 176
+# else
+# error Unknown chip
# endif
#endif
@@ -265,7 +269,7 @@
#endif /* CONFIG_CPU_SUBTYPE_SH7707 || CONFIG_CPU_SUBTYPE_SH7709 */
#if defined(CONFIG_CPU_SUBTYPE_SH7750) ||
defined(CONFIG_CPU_SUBTYPE_SH7751) || \
- defined(CONFIG_CPU_SUBTYPE_ST40STB1)
+ defined(CONFIG_CPU_SUBTYPE_ST40)
#define INTC_ICR 0xffd00000
#define INTC_ICR_NMIL (1<<15)
#define INTC_ICR_MAI (1<<14)
@@ -274,9 +278,15 @@
#define INTC_ICR_IRLM (1<<7)
#endif
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
#define INTC2_FIRST_IRQ 64
-#define NR_INTC2_IRQS 25
+#if defined(CONFIG_CPU_SUBTYPE_ST40STB1)
+#define NR_INTC2_IRQS 80
+#elif defined(CONFIG_CPU_SUBTYPE_ST40GX1)
+#define NR_INTC2_IRQS 112
+#else
+#error Unknown CPU
+#endif
#define INTC2_BASE0 0xfe080000
#define INTC2_INTC2MODE (INTC2_BASE0+0x80)
Index: include/asm-sh/pci.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/pci.h,v
retrieving revision 1.1.1.1.2.3
diff -u -r1.1.1.1.2.3 pci.h
--- include/asm-sh/pci.h 23 Mar 2003 14:22:02 -0000 1.1.1.1.2.3
+++ include/asm-sh/pci.h 19 Jun 2003 16:42:53 -0000
@@ -11,8 +11,8 @@
#define pcibios_assign_all_busses() 1
-#if defined(CONFIG_CPU_SUBTYPE_ST40STB1)
-/* These are currently the correct values for the STM overdrive board.
+#if defined(CONFIG_CPU_SUBTYPE_ST40)
+/* These are currently the correct values for the ST40 based chips.
* We need some way of setting this on a board specific way, it will
* not be the same on other boards I think
*/
Index: include/asm-sh/processor.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/processor.h,v
retrieving revision 1.1.1.1.2.3
diff -u -r1.1.1.1.2.3 processor.h
--- include/asm-sh/processor.h 29 May 2003 04:21:37 -0000 1.1.1.1.2.3
+++ include/asm-sh/processor.h 19 Jun 2003 16:42:53 -0000
@@ -23,8 +23,8 @@
enum cpu_type {
CPU_SH7708, /* Represents 7707, 7708, 7708S, 7708R, 7709 */
CPU_SH7729, /* Represents 7709A, 7729 */
- CPU_SH7750, /* Represents 7750, 7751 */
- CPU_ST40STB1,
+ CPU_SH7750, /* Represents 7750, 7751 */
+ CPU_ST40, /* Represents ST40STB1 and ST40GX1 */
CPU_SH_NONE
};
@@ -34,7 +34,7 @@
unsigned long loops_per_jiffy;
unsigned int cpu_clock, master_clock, bus_clock, module_clock;
-#ifdef CONFIG_CPU_SUBTYPE_ST40STB1
+#ifdef CONFIG_CPU_SUBTYPE_ST40
unsigned int memory_clock;
#endif
};
--
Alex, homepage: http://www.bennee.com/~alex/
If truth is beauty, how come no one has their hair done in the library?
-- Lily Tomlin
|
|
From: David W. <dw...@in...> - 2003-06-19 12:58:36
|
On Thu, 2003-06-19 at 13:48, David McCullough wrote: > Both, we build (HW and SW) routers and similar devices with SH4's in them. > The PCI peripherals we glue on have always worked fine. Not that I want to > provoke the big green monster ;-) Hmmm. I suspect the operative word there is 'we'. If the hardware engineers are on the same continent as you and your baseball bat, strangely fewer bizarre screwups happen along the way... :) -- dwmw2 |
|
From: David M. <da...@sn...> - 2003-06-19 12:50:00
|
Jivin David Woodhouse lays it down ... > On Wed, 2003-06-18 at 17:03, Paul Mundt wrote: > > No, its not obvious, because the code is a giant obfuscated mess that chooses > > to completely ignore existing APIs and define its own. > > ... and appears to pretend to support CONFIG_PCI_BIOS too... any > objections to me ripping that crap out of pci-sh7751.c and config.in for > a start? Get rid of it :-) > > > I can't say that the current SH PCI implementation has ever given me any > > > problems that were not of my own creation ;-) > > > > > Me neither, though it appears others aren't as lucky. > > I assume you speak only of the software side. If you include hardware in > that, then both my PCI analyser and I hate the pair of you with a venom > that only insane envy can cause. :) Both, we build (HW and SW) routers and similar devices with SH4's in them. The PCI peripherals we glue on have always worked fine. Not that I want to provoke the big green monster ;-) As for the Hitachi eval boards, I can't recall any PCI cards giving me problems, except with the V3 chip which was just nasty to getting working well :-( What sort of platforms/hardware have been plaguing you ? Cheers, Davidm -- David McCullough, da...@sn... Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org |
|
From: David W. <dw...@in...> - 2003-06-18 18:18:52
|
On Wed, 2003-06-18 at 17:34, Paul van Gool wrote: > Compiles and runs fine on my board. Thanks. -- dwmw2 |
|
From: Paul v. G. <pau...@ri...> - 2003-06-18 16:36:21
|
Compiles and runs fine on my board.
Paul
On Wed, Jun 18, 2003 at 09:29:05AM -0700, Paul van Gool wrote:
> I'll test it.
>
> Paul
>
> On Wed, Jun 18, 2003 at 05:26:01PM +0100, David Woodhouse wrote:
> > On Wed, 2003-06-18 at 17:15, Paul Mundt wrote:
> > > On Wed, Jun 18, 2003 at 05:10:42PM +0100, David Woodhouse wrote:
> > > > ... and appears to pretend to support CONFIG_PCI_BIOS too... any
> > > > objections to me ripping that crap out of pci-sh7751.c and config.in for
> > > > a start?
> > > >
> > > Not at all, please do! I was actually planning on this as well, but haven't
> > > been sufficiently bored enough to do it.
> >
> > I don't have one of these at the moment... someone wanna test what I
> > just committed?
> >
> > Index: ChangeLog
> > ===================================================================
> > RCS file: /cvsroot/linuxsh/linux/ChangeLog,v
> > retrieving revision 1.1.1.1.2.70
> > diff -u -p -r1.1.1.1.2.70 ChangeLog
> > --- ChangeLog 18 Jun 2003 14:17:04 -0000 1.1.1.1.2.70
> > +++ ChangeLog 18 Jun 2003 16:23:32 -0000
> > @@ -1,5 +1,7 @@
> > 2003-06-18 David Woodhouse <dw...@re...>
> >
> > + * arch/sh/config.in, arch/sh/kernel/pci-sh7751.c: Remove
> > + bogus CONFIG_PCI_BIOS noise.
> > * include/asm-sh/delay.h, arch/sh/lib/delay.c: Implement
> > ndelay() to match 2.4.21.
> >
> > Index: arch/sh/config.in
> > ===================================================================
> > RCS file: /cvsroot/linuxsh/linux/arch/sh/Attic/config.in,v
> > retrieving revision 1.1.1.1.2.9
> > diff -u -p -r1.1.1.1.2.9 config.in
> > --- arch/sh/config.in 29 May 2003 04:21:33 -0000 1.1.1.1.2.9
> > +++ arch/sh/config.in 18 Jun 2003 16:23:32 -0000
> > @@ -199,16 +199,6 @@ fi
> >
> > bool 'PCI support' CONFIG_PCI
> > if [ "$CONFIG_PCI" = "y" ]; then
> > - choice ' PCI access mode' \
> > - "BIOS CONFIG_PCI_GOBIOS \
> > - Direct CONFIG_PCI_GODIRECT \
> > - Any CONFIG_PCI_GOANY" Any
> > - if [ "$CONFIG_PCI_GOBIOS" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
> > - define_bool CONFIG_PCI_BIOS y
> > - fi
> > - if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
> > - define_bool CONFIG_PCI_DIRECT y
> > - fi
> > bool 'Cache and PCI noncoherent' CONFIG_SH_PCIDMA_NONCOHERENT
> > fi
> >
> > Index: arch/sh/kernel/pci-sh7751.c
> > ===================================================================
> > RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/Attic/pci-sh7751.c,v
> > retrieving revision 1.1.1.1.2.1
> > diff -u -p -r1.1.1.1.2.1 pci-sh7751.c
> > --- arch/sh/kernel/pci-sh7751.c 12 Dec 2001 00:11:59 -0000 1.1.1.1.2.1
> > +++ arch/sh/kernel/pci-sh7751.c 18 Jun 2003 16:23:32 -0000
> > @@ -38,8 +38,6 @@ struct pci_ops *pci_root_ops;
> > * Direct access to PCI hardware...
> > */
> >
> > -#ifdef CONFIG_PCI_DIRECT
> > -
> >
> > #define CONFIG_CMD(dev, where) (0x80000000 | (dev->bus->number << 16) | (dev->devfn << 8) | (where & ~3))
> >
> > @@ -226,20 +224,6 @@ struct pci_ops * __init pci_check_direct
> > return NULL;
> > }
> >
> > -#endif
> > -
> > -/*
> > - * BIOS32 and PCI BIOS handling.
> > - *
> > - * The BIOS version of the pci functions is not yet implemented but it is left
> > - * in for completeness. Currently an error will be generated at compile time.
> > - */
> > -
> > -#ifdef CONFIG_PCI_BIOS
> > -
> > -#error PCI BIOS is not yet supported on SH7751
> > -
> > -#endif /* CONFIG_PCI_BIOS */
> >
> > /***************************************************************************************/
> >
> > @@ -342,16 +326,9 @@ void __init pcibios_init(void)
> > struct pci_ops *dir = NULL;
> >
> > PCIDBG(1,"PCI: Starting intialization.\n");
> > -#ifdef CONFIG_PCI_BIOS
> > - if ((pci_probe & PCI_PROBE_BIOS) && ((bios = pci_find_bios()))) {
> > - pci_probe |= PCI_BIOS_SORT;
> > - pci_bios_present = 1;
> > - }
> > -#endif
> > -#ifdef CONFIG_PCI_DIRECT
> > +
> > if (pci_probe & PCI_PROBE_CONF1 )
> > dir = pci_check_direct();
> > -#endif
> > if (dir) {
> > pci_root_ops = dir;
> > if(!pcibios_init_platform())
> > @@ -372,11 +349,6 @@ void __init pcibios_init(void)
> > pci_fixup_irqs(pcibios_swizzle, pcibios_lookup_irq);
> > pcibios_fixup_peer_bridges();
> > pcibios_resource_survey();
> > -
> > -#ifdef CONFIG_PCI_BIOS
> > - if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
> > - pcibios_sort();
> > -#endif
> > }
> >
> > char * __init pcibios_setup(char *str)
> > @@ -384,29 +356,10 @@ char * __init pcibios_setup(char *str)
> > if (!strcmp(str, "off")) {
> > pci_probe = 0;
> > return NULL;
> > - }
> > -#ifdef CONFIG_PCI_BIOS
> > - else if (!strcmp(str, "bios")) {
> > - pci_probe = PCI_PROBE_BIOS;
> > - return NULL;
> > - } else if (!strcmp(str, "nobios")) {
> > - pci_probe &= ~PCI_PROBE_BIOS;
> > - return NULL;
> > - } else if (!strcmp(str, "nosort")) {
> > - pci_probe |= PCI_NO_SORT;
> > - return NULL;
> > - } else if (!strcmp(str, "biosirq")) {
> > - pci_probe |= PCI_BIOS_IRQ_SCAN;
> > - return NULL;
> > - }
> > -#endif
> > -#ifdef CONFIG_PCI_DIRECT
> > - else if (!strcmp(str, "conf1")) {
> > + } else if (!strcmp(str, "conf1")) {
> > pci_probe = PCI_PROBE_CONF1 | PCI_NO_CHECKS;
> > return NULL;
> > - }
> > -#endif
> > - else if (!strcmp(str, "rom")) {
> > + } else if (!strcmp(str, "rom")) {
> > pci_probe |= PCI_ASSIGN_ROMS;
> > return NULL;
> > } else if (!strncmp(str, "lastbus=", 8)) {
> >
> >
> >
> >
> > --
> > dwmw2
>
> --
> Paul van Gool Rincon Networks
> pau...@ri... (805)-705-1442
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
--
Paul van Gool Rincon Networks
pau...@ri... (805)-705-1442
|
|
From: Paul v. G. <pau...@ri...> - 2003-06-18 16:29:53
|
I'll test it.
Paul
On Wed, Jun 18, 2003 at 05:26:01PM +0100, David Woodhouse wrote:
> On Wed, 2003-06-18 at 17:15, Paul Mundt wrote:
> > On Wed, Jun 18, 2003 at 05:10:42PM +0100, David Woodhouse wrote:
> > > ... and appears to pretend to support CONFIG_PCI_BIOS too... any
> > > objections to me ripping that crap out of pci-sh7751.c and config.in for
> > > a start?
> > >
> > Not at all, please do! I was actually planning on this as well, but haven't
> > been sufficiently bored enough to do it.
>
> I don't have one of these at the moment... someone wanna test what I
> just committed?
>
> Index: ChangeLog
> ===================================================================
> RCS file: /cvsroot/linuxsh/linux/ChangeLog,v
> retrieving revision 1.1.1.1.2.70
> diff -u -p -r1.1.1.1.2.70 ChangeLog
> --- ChangeLog 18 Jun 2003 14:17:04 -0000 1.1.1.1.2.70
> +++ ChangeLog 18 Jun 2003 16:23:32 -0000
> @@ -1,5 +1,7 @@
> 2003-06-18 David Woodhouse <dw...@re...>
>
> + * arch/sh/config.in, arch/sh/kernel/pci-sh7751.c: Remove
> + bogus CONFIG_PCI_BIOS noise.
> * include/asm-sh/delay.h, arch/sh/lib/delay.c: Implement
> ndelay() to match 2.4.21.
>
> Index: arch/sh/config.in
> ===================================================================
> RCS file: /cvsroot/linuxsh/linux/arch/sh/Attic/config.in,v
> retrieving revision 1.1.1.1.2.9
> diff -u -p -r1.1.1.1.2.9 config.in
> --- arch/sh/config.in 29 May 2003 04:21:33 -0000 1.1.1.1.2.9
> +++ arch/sh/config.in 18 Jun 2003 16:23:32 -0000
> @@ -199,16 +199,6 @@ fi
>
> bool 'PCI support' CONFIG_PCI
> if [ "$CONFIG_PCI" = "y" ]; then
> - choice ' PCI access mode' \
> - "BIOS CONFIG_PCI_GOBIOS \
> - Direct CONFIG_PCI_GODIRECT \
> - Any CONFIG_PCI_GOANY" Any
> - if [ "$CONFIG_PCI_GOBIOS" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
> - define_bool CONFIG_PCI_BIOS y
> - fi
> - if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
> - define_bool CONFIG_PCI_DIRECT y
> - fi
> bool 'Cache and PCI noncoherent' CONFIG_SH_PCIDMA_NONCOHERENT
> fi
>
> Index: arch/sh/kernel/pci-sh7751.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/Attic/pci-sh7751.c,v
> retrieving revision 1.1.1.1.2.1
> diff -u -p -r1.1.1.1.2.1 pci-sh7751.c
> --- arch/sh/kernel/pci-sh7751.c 12 Dec 2001 00:11:59 -0000 1.1.1.1.2.1
> +++ arch/sh/kernel/pci-sh7751.c 18 Jun 2003 16:23:32 -0000
> @@ -38,8 +38,6 @@ struct pci_ops *pci_root_ops;
> * Direct access to PCI hardware...
> */
>
> -#ifdef CONFIG_PCI_DIRECT
> -
>
> #define CONFIG_CMD(dev, where) (0x80000000 | (dev->bus->number << 16) | (dev->devfn << 8) | (where & ~3))
>
> @@ -226,20 +224,6 @@ struct pci_ops * __init pci_check_direct
> return NULL;
> }
>
> -#endif
> -
> -/*
> - * BIOS32 and PCI BIOS handling.
> - *
> - * The BIOS version of the pci functions is not yet implemented but it is left
> - * in for completeness. Currently an error will be generated at compile time.
> - */
> -
> -#ifdef CONFIG_PCI_BIOS
> -
> -#error PCI BIOS is not yet supported on SH7751
> -
> -#endif /* CONFIG_PCI_BIOS */
>
> /***************************************************************************************/
>
> @@ -342,16 +326,9 @@ void __init pcibios_init(void)
> struct pci_ops *dir = NULL;
>
> PCIDBG(1,"PCI: Starting intialization.\n");
> -#ifdef CONFIG_PCI_BIOS
> - if ((pci_probe & PCI_PROBE_BIOS) && ((bios = pci_find_bios()))) {
> - pci_probe |= PCI_BIOS_SORT;
> - pci_bios_present = 1;
> - }
> -#endif
> -#ifdef CONFIG_PCI_DIRECT
> +
> if (pci_probe & PCI_PROBE_CONF1 )
> dir = pci_check_direct();
> -#endif
> if (dir) {
> pci_root_ops = dir;
> if(!pcibios_init_platform())
> @@ -372,11 +349,6 @@ void __init pcibios_init(void)
> pci_fixup_irqs(pcibios_swizzle, pcibios_lookup_irq);
> pcibios_fixup_peer_bridges();
> pcibios_resource_survey();
> -
> -#ifdef CONFIG_PCI_BIOS
> - if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
> - pcibios_sort();
> -#endif
> }
>
> char * __init pcibios_setup(char *str)
> @@ -384,29 +356,10 @@ char * __init pcibios_setup(char *str)
> if (!strcmp(str, "off")) {
> pci_probe = 0;
> return NULL;
> - }
> -#ifdef CONFIG_PCI_BIOS
> - else if (!strcmp(str, "bios")) {
> - pci_probe = PCI_PROBE_BIOS;
> - return NULL;
> - } else if (!strcmp(str, "nobios")) {
> - pci_probe &= ~PCI_PROBE_BIOS;
> - return NULL;
> - } else if (!strcmp(str, "nosort")) {
> - pci_probe |= PCI_NO_SORT;
> - return NULL;
> - } else if (!strcmp(str, "biosirq")) {
> - pci_probe |= PCI_BIOS_IRQ_SCAN;
> - return NULL;
> - }
> -#endif
> -#ifdef CONFIG_PCI_DIRECT
> - else if (!strcmp(str, "conf1")) {
> + } else if (!strcmp(str, "conf1")) {
> pci_probe = PCI_PROBE_CONF1 | PCI_NO_CHECKS;
> return NULL;
> - }
> -#endif
> - else if (!strcmp(str, "rom")) {
> + } else if (!strcmp(str, "rom")) {
> pci_probe |= PCI_ASSIGN_ROMS;
> return NULL;
> } else if (!strncmp(str, "lastbus=", 8)) {
>
>
>
>
> --
> dwmw2
--
Paul van Gool Rincon Networks
pau...@ri... (805)-705-1442
|
|
From: David W. <dw...@in...> - 2003-06-18 16:27:16
|
On Wed, 2003-06-18 at 17:15, Paul Mundt wrote:
> On Wed, Jun 18, 2003 at 05:10:42PM +0100, David Woodhouse wrote:
> > ... and appears to pretend to support CONFIG_PCI_BIOS too... any
> > objections to me ripping that crap out of pci-sh7751.c and config.in for
> > a start?
> >
> Not at all, please do! I was actually planning on this as well, but haven't
> been sufficiently bored enough to do it.
I don't have one of these at the moment... someone wanna test what I
just committed?
Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/linux/ChangeLog,v
retrieving revision 1.1.1.1.2.70
diff -u -p -r1.1.1.1.2.70 ChangeLog
--- ChangeLog 18 Jun 2003 14:17:04 -0000 1.1.1.1.2.70
+++ ChangeLog 18 Jun 2003 16:23:32 -0000
@@ -1,5 +1,7 @@
2003-06-18 David Woodhouse <dw...@re...>
+ * arch/sh/config.in, arch/sh/kernel/pci-sh7751.c: Remove
+ bogus CONFIG_PCI_BIOS noise.
* include/asm-sh/delay.h, arch/sh/lib/delay.c: Implement
ndelay() to match 2.4.21.
Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/Attic/config.in,v
retrieving revision 1.1.1.1.2.9
diff -u -p -r1.1.1.1.2.9 config.in
--- arch/sh/config.in 29 May 2003 04:21:33 -0000 1.1.1.1.2.9
+++ arch/sh/config.in 18 Jun 2003 16:23:32 -0000
@@ -199,16 +199,6 @@ fi
bool 'PCI support' CONFIG_PCI
if [ "$CONFIG_PCI" = "y" ]; then
- choice ' PCI access mode' \
- "BIOS CONFIG_PCI_GOBIOS \
- Direct CONFIG_PCI_GODIRECT \
- Any CONFIG_PCI_GOANY" Any
- if [ "$CONFIG_PCI_GOBIOS" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
- define_bool CONFIG_PCI_BIOS y
- fi
- if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
- define_bool CONFIG_PCI_DIRECT y
- fi
bool 'Cache and PCI noncoherent' CONFIG_SH_PCIDMA_NONCOHERENT
fi
Index: arch/sh/kernel/pci-sh7751.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/Attic/pci-sh7751.c,v
retrieving revision 1.1.1.1.2.1
diff -u -p -r1.1.1.1.2.1 pci-sh7751.c
--- arch/sh/kernel/pci-sh7751.c 12 Dec 2001 00:11:59 -0000 1.1.1.1.2.1
+++ arch/sh/kernel/pci-sh7751.c 18 Jun 2003 16:23:32 -0000
@@ -38,8 +38,6 @@ struct pci_ops *pci_root_ops;
* Direct access to PCI hardware...
*/
-#ifdef CONFIG_PCI_DIRECT
-
#define CONFIG_CMD(dev, where) (0x80000000 | (dev->bus->number << 16) | (dev->devfn << 8) | (where & ~3))
@@ -226,20 +224,6 @@ struct pci_ops * __init pci_check_direct
return NULL;
}
-#endif
-
-/*
- * BIOS32 and PCI BIOS handling.
- *
- * The BIOS version of the pci functions is not yet implemented but it is left
- * in for completeness. Currently an error will be generated at compile time.
- */
-
-#ifdef CONFIG_PCI_BIOS
-
-#error PCI BIOS is not yet supported on SH7751
-
-#endif /* CONFIG_PCI_BIOS */
/***************************************************************************************/
@@ -342,16 +326,9 @@ void __init pcibios_init(void)
struct pci_ops *dir = NULL;
PCIDBG(1,"PCI: Starting intialization.\n");
-#ifdef CONFIG_PCI_BIOS
- if ((pci_probe & PCI_PROBE_BIOS) && ((bios = pci_find_bios()))) {
- pci_probe |= PCI_BIOS_SORT;
- pci_bios_present = 1;
- }
-#endif
-#ifdef CONFIG_PCI_DIRECT
+
if (pci_probe & PCI_PROBE_CONF1 )
dir = pci_check_direct();
-#endif
if (dir) {
pci_root_ops = dir;
if(!pcibios_init_platform())
@@ -372,11 +349,6 @@ void __init pcibios_init(void)
pci_fixup_irqs(pcibios_swizzle, pcibios_lookup_irq);
pcibios_fixup_peer_bridges();
pcibios_resource_survey();
-
-#ifdef CONFIG_PCI_BIOS
- if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
- pcibios_sort();
-#endif
}
char * __init pcibios_setup(char *str)
@@ -384,29 +356,10 @@ char * __init pcibios_setup(char *str)
if (!strcmp(str, "off")) {
pci_probe = 0;
return NULL;
- }
-#ifdef CONFIG_PCI_BIOS
- else if (!strcmp(str, "bios")) {
- pci_probe = PCI_PROBE_BIOS;
- return NULL;
- } else if (!strcmp(str, "nobios")) {
- pci_probe &= ~PCI_PROBE_BIOS;
- return NULL;
- } else if (!strcmp(str, "nosort")) {
- pci_probe |= PCI_NO_SORT;
- return NULL;
- } else if (!strcmp(str, "biosirq")) {
- pci_probe |= PCI_BIOS_IRQ_SCAN;
- return NULL;
- }
-#endif
-#ifdef CONFIG_PCI_DIRECT
- else if (!strcmp(str, "conf1")) {
+ } else if (!strcmp(str, "conf1")) {
pci_probe = PCI_PROBE_CONF1 | PCI_NO_CHECKS;
return NULL;
- }
-#endif
- else if (!strcmp(str, "rom")) {
+ } else if (!strcmp(str, "rom")) {
pci_probe |= PCI_ASSIGN_ROMS;
return NULL;
} else if (!strncmp(str, "lastbus=", 8)) {
--
dwmw2
|
|
From: Paul M. <le...@li...> - 2003-06-18 16:15:16
|
On Wed, Jun 18, 2003 at 05:10:42PM +0100, David Woodhouse wrote: > ... and appears to pretend to support CONFIG_PCI_BIOS too... any > objections to me ripping that crap out of pci-sh7751.c and config.in for > a start? >=20 Not at all, please do! I was actually planning on this as well, but haven't been sufficiently bored enough to do it. |
|
From: David W. <dw...@in...> - 2003-06-18 16:12:00
|
On Wed, 2003-06-18 at 17:03, Paul Mundt wrote: > No, its not obvious, because the code is a giant obfuscated mess that chooses > to completely ignore existing APIs and define its own. ... and appears to pretend to support CONFIG_PCI_BIOS too... any objections to me ripping that crap out of pci-sh7751.c and config.in for a start? > > I can't say that the current SH PCI implementation has ever given me any > > problems that were not of my own creation ;-) > > > Me neither, though it appears others aren't as lucky. I assume you speak only of the software side. If you include hardware in that, then both my PCI analyser and I hate the pair of you with a venom that only insane envy can cause. :) -- dwmw2 |
|
From: Jeremy S. <jas...@pa...> - 2003-06-18 16:08:33
|
Hitachi had some patches on their website for changes to the 7751se initialization and setup that probably do better than what's in CVS and might be worth looking at (sorry, I don't have the link handy. ) [In that setup all the interrupts are routed through the ALi part rather than the FPGA, but if I recall correctly that patch only initializes one of the PCI slots.] As far as bootloaders, I remember tweaking sh-ipl+g/sh-ethboot so it resets the PCI regs in the AMD part if uses for download because of the linux-reusing-configured-addresses thing; but I can see arguments both ways. --Jeremy Siegel |
|
From: Paul M. <le...@li...> - 2003-06-18 16:03:22
|
On Wed, Jun 18, 2003 at 11:57:47PM +1000, David McCullough wrote:
> Having looked at it, it is not totally obvious where and why resources
> get assigned :-)
>=20
No, its not obvious, because the code is a giant obfuscated mess that choos=
es
to completely ignore existing APIs and define its own.
If we look where things start out:
pci_root_bus =3D pci_scan_bus(0, pci_root_ops, NULL);
//pci_assign_unassigned_resources();
pci_fixup_irqs(pcibios_swizzle, pcibios_lookup_irq);
pcibios_fixup_peer_bridges();
pcibios_resource_survey();
Even the pcibios_fixup_peer_bridges() looks questionable, though I'm inclin=
ed
to leave it alone unless it creates problems for anyone.
Following the survey code:
void __init pcibios_resource_survey(void)
{
PCIDBG(1,"PCI: Allocating resources\n");
pcibios_allocate_bus_resources(&pci_root_buses);
pcibios_allocate_resources(0);
pcibios_allocate_resources(1);
pcibios_assign_resources();
}
This steps through a series of obscure resource allocation functions. Each =
of
which seem to generally iterate over all the devices and all available
resources for the device.
/*
* We shall assign a new address to this resource, either because
* the BIOS forgot to do so or because we have decided the old
* address was unusable for some reason.
*/
if (!r->start && r->end)
pci_assign_resource(dev, idx);
I think most of this can be greatly simplified with just calling
pci_assign_unassigned_resources() directly. I'll come up with a patch for t=
his,
we'll just have to make sure it doesn't break anyones 7751 setup (I'll test
this on the SME550).
> I would only say that on a PC, like it or not, the BIOS does all this
> setup before it gets to the kernel. Not that this is a reason to do the
> same on SH, just an example where it is done this way. Also on our x86
> platforms (which do not have a real PCI bios), we assign all resources in=
the
> bootloader/bios substitute that we use. Linux then goes on to use those
> values that the bootloader assigned.
>=20
On a PC, the BIOS usually has some notion of a clue. On everything else, the
boot loader is usually some clue-impaired hack to attempt some vague method
of loading an image onto it to get real work done (or in some cases, don't =
even
support loading and force you to write a shell script to write your binary =
out
through the write byte command, yay cyclone!).
I would find it extremely odd where the boot loader would know whats best f=
or
the PCI devices (your case seems pretty well isolated). Again, if you _need_
this functionality, there's other things we can look at.. such as wiring the
BAR mappings into the TLB, and using those later, prior to removing the
entries. Or potentially even something clean.
> For our SH boards, the bootloader needs to program up the NIC's as they
> don't always have eeproms fitted. So it assigns resources so it can
> talk to the devices. It just happened that the kernel went on to
> use those values, we are not relying on this functionality in any way,
> but since we already have x86 products doing similar things it didn't
> seem out of place :-).
>=20
Okay. I'll come up with a workaround then and we can hope that those things
keep working ;-)
> The bootloader on a device probably knows more about the intimate details
> of the of the HW than the linux PCI subsystem. If the bootloader sets up=
all
> the devices and their resources, I would tend to think it knew what it w=
as
> doing and leave well alone. If the resources for a card were bogus, then=
I
> would assume it is safe to reassign the resources.
>=20
Bootloaders are traditionally stupid. Half of them refuse to touch a device
if its not a NIC, since it only serves a use for TFTP.
I can only think of a tiny fraction of uses where we actually _need_ to keep
around mappings that the bootloader setup. (One of these is for when stupid
hardware people put a UART off PCI to maintain buzzword compliance (or simp=
ly
to spite the software people) and force you to setup the PCI mappings as wi=
red
TLB entries so you can use this thing as an early console -- at least that's
what I had to do as a workaround for MIPS).
> I can't say that the current SH PCI implementation has ever given me any
> problems that were not of my own creation ;-)
>=20
Me neither, though it appears others aren't as lucky.
|
|
From: David W. <dw...@in...> - 2003-06-18 14:37:00
|
The comment above pcibios_align_resource() in arch/sh/kernel/pcibios.c says... /* * We need to avoid collisions with `mirrored' VGA ports * and other strange ISA hardware, so we always want the * addresses to be allocated in the 0x000-0x0ff region * modulo 0x400. */ That isn't strictly true. We don't need to do that. The reason the PCI spec talks about such a thing is because once upon a time in a PeeCee, I/O addresses such that (addr & 0x3ff)>0xff were aliases to ISA I/O ports -- 0x6f8 was an alias for 0x2f8, for example -- and some DOS drivers were, bizarrely, written to make use of that fact and not use the 'canonical' address below 0x400. We have no such drivers here, and we can refrain from setting the ISA Enable bit in the control register of any PCI-PCI bridge, which would prevent the bridge from forwarding transactions to such addresses... do we really need this alignment? On SH we tend to have fairly limited windows into the PCI I/O and memory space -- why waste it? -- dwmw2 |
|
From: David W. <dw...@in...> - 2003-06-18 14:20:49
|
On Fri, 2003-06-13 at 13:24, Alex Bennee wrote:
> This is needed if your building IDE stuff on the 2.4 tree. Is there
> anyone who formally looks over the 2.4 CVS tree for comitting stuff or
> is submitting patches the mailing list likely to get picked up?
Evidently not but I seem to still have commit privs so I just committed
it, having made a Changelog entry and implemented the out-of-line
version for non-constant ndelay()...
Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/linux/ChangeLog,v
retrieving revision 1.1.1.1.2.69
diff -u -p -r1.1.1.1.2.69 ChangeLog
--- ChangeLog 16 Jun 2003 12:05:20 -0000 1.1.1.1.2.69
+++ ChangeLog 18 Jun 2003 14:14:35 -0000
@@ -1,3 +1,8 @@
+2003-06-18 David Woodhouse <dw...@re...>
+
+ * include/asm-sh/delay.h, arch/sh/lib/delay.c: Implement
+ ndelay() to match 2.4.21.
+
2003-06-16 Stuart Menefy <stu...@st...>
Merge 2.4.21.
Index: include/asm-sh/delay.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/delay.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 delay.h
--- include/asm-sh/delay.h 15 Oct 2001 20:45:06 -0000 1.1.1.1
+++ include/asm-sh/delay.h 18 Jun 2003 14:14:35 -0000
@@ -10,11 +10,16 @@
extern void __bad_udelay(void);
extern void __udelay(unsigned long usecs);
+extern void __ndelay(unsigned long nsecs);
extern void __const_udelay(unsigned long usecs);
extern void __delay(unsigned long loops);
#define udelay(n) (__builtin_constant_p(n) ? \
((n) > 20000 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \
__udelay(n))
+
+#define ndelay(n) (__builtin_constant_p(n) ? \
+ ((n) > 20000 ? __bad_ndelay() : __const_udelay((n) * 5ul)) : \
+ __ndelay(n))
#endif /* __ASM_SH_DELAY_H */
Index: arch/sh/lib/delay.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/lib/Attic/delay.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 delay.c
--- arch/sh/lib/delay.c 15 Oct 2001 20:44:53 -0000 1.1.1.1
+++ arch/sh/lib/delay.c 18 Jun 2003 14:14:35 -0000
@@ -33,3 +33,8 @@ void __udelay(unsigned long usecs)
{
__const_udelay(usecs * 0x000010c6); /* 2**32 / 1000000 */
}
+
+void __ndelay(unsigned long nsecs)
+{
+ __const_udelay(nsecs * 5); /* 2**32 / 1000000000 (rounded up) */
+}
--
dwmw2
|
|
From: David M. <da...@sn...> - 2003-06-18 13:57:57
|
Jivin Paul Mundt lays it down ... > On Wed, Jun 18, 2003 at 10:42:47AM +1000, David McCullough wrote: > > > In arch/sh/kernel/pci-sh7751.c, in pcibios_init, the call to > > > pci_assign_unassigned_resources() is commented out (linux 2.4). It still > > > seems to be commented out in the CVS repository. Anybody know why? > > > > Not sure how this helps you but it is commented out in our tree and I can > > assure you that pci cards are working on our 7751 :-) > > The existing code for the 7751 PCI for managing resources looks seriously > questionable. It seems to do all of its own resource management through the > pcibios_resource_survey() interface. Most of this looks like it can be cleaned > up quite a bit. Having looked at it, it is not totally obvious where and why resources get assigned :-) > > I fixed a problem recently where I went through all the PCI resource > > code trying to figure out what it was doing wrong. Turned out the > > bootloader was assigning some bogus resources to the PCI device > > which linux was then happy to use. To the point where the card needed > > memory but was given an IO address ! > > This doesn't seem like a useful approach at all. This sounds fine from a > debugging standpoint when trying to get PCI up and running in the first place, > but definitely not as a long term solution. If there's any reason why someone > needs to keep the original mappings for a device, there's other ways they can > do that. I would only say that on a PC, like it or not, the BIOS does all this setup before it gets to the kernel. Not that this is a reason to do the same on SH, just an example where it is done this way. Also on our x86 platforms (which do not have a real PCI bios), we assign all resources in the bootloader/bios substitute that we use. Linux then goes on to use those values that the bootloader assigned. For our SH boards, the bootloader needs to program up the NIC's as they don't always have eeproms fitted. So it assigns resources so it can talk to the devices. It just happened that the kernel went on to use those values, we are not relying on this functionality in any way, but since we already have x86 products doing similar things it didn't seem out of place :-). > Presumably we should just teardown any mappings the boot loader might > setup and just use pci_assign_unassigned_resources() directly. > > Can anyone think of any reasons not to do this? The bootloader on a device probably knows more about the intimate details of the of the HW than the linux PCI subsystem. If the bootloader sets up all the devices and their resources, I would tend to think it knew what it was doing and leave well alone. If the resources for a card were bogus, then I would assume it is safe to reassign the resources. I can't say that the current SH PCI implementation has ever given me any problems that were not of my own creation ;-) Cheers, Davidm -- David McCullough, da...@sn... Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org |
|
From: David M. <da...@sn...> - 2003-06-18 13:31:04
|
Jivin Paul van Gool lays it down ... > On Wed, Jun 18, 2003 at 10:42:47AM +1000, David McCullough wrote: > > Not sure how this helps you but it is commented out in our tree and I can > > assure you that pci cards are working on our 7751 :-) > > That's indeed funny ;-). Both my PCI cards work fine now btw. > > > If the device has no resources assigned at boot, linux will do it for > > you. Is it possible your bootloader is somehow giving these devices the > > strange addresses ? > > I'll dig into the redboot code then. As far as I know it doesn't assign > resources but who knows. What bootloader do you use? It's our own. It's pretty simple but it does need to talk to the network devices to setup a few things as we don't have eeproms fitted, and to do this it needs to assign some resources. Cheers, Davidm -- David McCullough, da...@sn... Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org |
|
From: David W. <dw...@in...> - 2003-06-18 06:42:10
|
On Wed, 2003-06-18 at 02:17, Paul Mundt wrote: > The existing code for the 7751 PCI for managing resources looks seriously > questionable. It seems to do all of its own resource management through the > pcibios_resource_survey() interface. Most of this looks like it can be cleaned > up quite a bit. Is there any particular reason why this part of the PCI code can't be shared? > Can anyone think of any reasons not to do this? On a PeeCee we try to avoid it because the BIOS may know better than us. On SH I see no reason not do to it. -- dwmw2 |
|
From: Paul v. G. <pau...@ri...> - 2003-06-18 01:31:06
|
On Tue, Jun 17, 2003 at 09:17:32PM -0400, Paul Mundt wrote: > Presumably we should just teardown any mappings the boot loader might setup and > just use pci_assign_unassigned_resources() directly. > > Can anyone think of any reasons not to do this? As far as I can tell, that's a reasonable approach. Let me know if you want me to test anything. Thanks. Paul -- Paul van Gool Rincon Networks pau...@ri... (805)-705-1442 |
|
From: Paul M. <le...@li...> - 2003-06-18 01:17:53
|
On Wed, Jun 18, 2003 at 10:42:47AM +1000, David McCullough wrote: > > In arch/sh/kernel/pci-sh7751.c, in pcibios_init, the call to > > pci_assign_unassigned_resources() is commented out (linux 2.4). It still > > seems to be commented out in the CVS repository. Anybody know why? >=20 > Not sure how this helps you but it is commented out in our tree and I can > assure you that pci cards are working on our 7751 :-) >=20 The existing code for the 7751 PCI for managing resources looks seriously questionable. It seems to do all of its own resource management through the pcibios_resource_survey() interface. Most of this looks like it can be clea= ned up quite a bit. > I fixed a problem recently where I went through all the PCI resource > code trying to figure out what it was doing wrong. Turned out the > bootloader was assigning some bogus resources to the PCI device > which linux was then happy to use. To the point where the card needed > memory but was given an IO address ! >=20 This doesn't seem like a useful approach at all. This sounds fine from a debugging standpoint when trying to get PCI up and running in the first pla= ce, but definitely not as a long term solution. If there's any reason why someo= ne needs to keep the original mappings for a device, there's other ways they c= an do that. Presumably we should just teardown any mappings the boot loader might setup= and just use pci_assign_unassigned_resources() directly. Can anyone think of any reasons not to do this? |
|
From: Paul v. G. <pau...@ri...> - 2003-06-18 01:00:12
|
On Wed, Jun 18, 2003 at 10:42:47AM +1000, David McCullough wrote: > Not sure how this helps you but it is commented out in our tree and I can > assure you that pci cards are working on our 7751 :-) That's indeed funny ;-). Both my PCI cards work fine now btw. > If the device has no resources assigned at boot, linux will do it for > you. Is it possible your bootloader is somehow giving these devices the > strange addresses ? I'll dig into the redboot code then. As far as I know it doesn't assign resources but who knows. What bootloader do you use? Thanks. Paul -- Paul van Gool Rincon Networks pau...@ri... (805)-705-1442 |
|
From: David M. <da...@sn...> - 2003-06-18 00:44:06
|
Jivin Paul van Gool lays it down ... > Finally some success! ;-) > > In arch/sh/kernel/pci-sh7751.c, in pcibios_init, the call to > pci_assign_unassigned_resources() is commented out (linux 2.4). It still > seems to be commented out in the CVS repository. Anybody know why? Not sure how this helps you but it is commented out in our tree and I can assure you that pci cards are working on our 7751 :-) I fixed a problem recently where I went through all the PCI resource code trying to figure out what it was doing wrong. Turned out the bootloader was assigning some bogus resources to the PCI device which linux was then happy to use. To the point where the card needed memory but was given an IO address ! If the device has no resources assigned at boot, linux will do it for you. Is it possible your bootloader is somehow giving these devices the strange addresses ? Cheers, Davidm -- David McCullough, da...@sn... Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org |
|
From: Mitch D. <mj...@al...> - 2003-06-17 23:01:24
|
David Woodhouse wrote: > On Tue, 2003-06-17 at 19:58, Paul van Gool wrote: > >>PCI: Error mapping IRQ on device ... >>PCI: Bad IRQ mapping request for slot ... > > > Hmmm. That looks unhappy but leave it for now -- we can deal with > interrupts once you have the resource allocation working and can > actually talk to the hardware in question. > >>PCI: pcibios_allocate_resources pass 0 called >>PCI: Resource 00001000-00001fff (f=1208, d=0, p=0) >>PCI: Resource 00000020-0000003f (f=101, d=0, p=0) >>PCI: Resource 00000080-000000ff (f=101, d=0, p=0) >>PCI: Resource 00000100-0000013f (f=101, d=0, p=0) >>PCI: Resource 00000140-0000015f (f=101, d=0, p=0) >>PCI: Resource 00002000-00002fff (f=200, d=0, p=0) > > OK, the resources it's allocating there are completely bogus as far as I > can tell. Can you double-check the values of PCIBIOS_MIN_MEM and > PCIBIOS_MIN_IO as seen in drivers/pci/setup-res.c::pci_assign_resource() They look a bit "PC-ish" to me... Mitch. |
25 messages has been excluded from this view by a project administrator.
