[U-Boot-Users] [patch] rtl8139.c: use PCI IO map

[U-Boot-Users] [patch] rtl8139.c: use PCI IO map

[Lucas Jin]

Signed-off-by: Lucas Jin <lucasjin@gmail.com>

--- ./drivers/rtl8139.c.orig	2007-10-12 22:17:52.000000000 +0800
+++ ./drivers/rtl8139.c	2007-10-13 17:34:40.117515408 +0800
@@ -104,8 +104,8 @@
 #undef DEBUG_RX
 
 #define currticks()	get_timer(0)
-#define bus_to_phys(a)	pci_mem_to_phys((pci_dev_t)dev->priv, a)
-#define phys_to_bus(a)	pci_phys_to_mem((pci_dev_t)dev->priv, a)
+#define bus_to_phys(a)	pci_io_to_phys((pci_dev_t)dev->priv, a)
+#define phys_to_bus(a)	pci_phys_to_io((pci_dev_t)dev->priv, a)
 
 /* Symbolic offsets to registers. */
 enum RTL8139_registers {
@@ -213,7 +213,7 @@
 		if ((devno = pci_find_devices(supported, idx++)) < 0)
 			break;
 
-		pci_read_config_dword(devno, PCI_BASE_ADDRESS_1, &iobase);
+		pci_read_config_dword(devno, PCI_BASE_ADDRESS_0, &iobase);
 		iobase &= ~0xf;
 
 		debug ("rtl8139: REALTEK RTL8139 @0x%x\n", iobase);

  				
--------------
Lucas Jin 

[U-Boot-Users] [patch] rtl8139.c: use PCI IO map

[Wolfgang Denk]

In message <200710131722183904740@gmail.com> you wrote:
>
> Signed-off-by: Lucas Jin <lucasjin@gmail.com>
> 
> --- ./drivers/rtl8139.c.orig	2007-10-12 22:17:52.000000000 +0800
> +++ ./drivers/rtl8139.c	2007-10-13 17:34:40.117515408 +0800

Could you please explain which problem this patch is supposed to fix?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nearly everyone is in favor of going  to  heaven  but  too  many  are
hoping  they'll  live  long  enough  to see an easing of the entrance
requirements. Never appeal to a man's "better nature." he  might  not
have one.

[U-Boot-Users] [patch] rtl8139.c: use PCI IO map

[Lucas Jin]

Wolfgang Denk Wrote:

>In message <200710131722183904740@gmail.com> you wrote:
>>
>> Signed-off-by: Lucas Jin <lucasjin@gmail.com>
>> 
>> --- ./drivers/rtl8139.c.orig	2007-10-12 22:17:52.000000000 +0800
>> +++ ./drivers/rtl8139.c	2007-10-13 17:34:40.117515408 +0800
>
>Could you please explain which problem this patch is supposed to fix?

The rtl8139 specification says the configuration registers can be accessed through PCI memory mapping or PCI IO mapping.

The u-boot driver uses PCI memory mapping, but it doesn't work, so I changed it to PCI IO mapping.

The driver of rtl8139 in Linux Kernel also uses PCI IO mapping to access the configuration registers. 

>
>Best regards,
>
>Wolfgang Denk
>
>-- 
>DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>Nearly everyone is in favor of going  to  heaven  but  too  many  are
>hoping  they'll  live  long  enough  to see an easing of the entrance
>requirements. Never appeal to a man's "better nature." he  might  not
>have one.



------------------		
Thanks		 
Lucas Jin

[U-Boot-Users] [patch] rtl8139.c: use PCI IO map

[Shinya Kuribayashi]

Lucas Jin wrote:
> Wolfgang Denk Wrote:
> 
>> In message <200710131722183904740@gmail.com> you wrote:
>>> Signed-off-by: Lucas Jin <lucasjin@gmail.com>
>>>
>>> --- ./drivers/rtl8139.c.orig	2007-10-12 22:17:52.000000000 +0800
>>> +++ ./drivers/rtl8139.c	2007-10-13 17:34:40.117515408 +0800
>> Could you please explain which problem this patch is supposed to fix?
> 
> The rtl8139 specification says the configuration registers can be accessed through PCI memory mapping or PCI IO mapping.
> 
> The u-boot driver uses PCI memory mapping, but it doesn't work, so I changed it to PCI IO mapping.

On my target RTL8139 or its variant works fine without such a change.
Why do you think doesn't work? Could you elaborate please?

> The driver of rtl8139 in Linux Kernel also uses PCI IO mapping to access the configuration registers. 

Do you mean CONFIG_8139TOO_PIO?

thanks,

    Shinya

[U-Boot-Users] [patch] rtl8139.c: use PCI IO map

[Lucas Jin]

Shinya Kuribayashi Wrote:

>Lucas Jin wrote:
>> Wolfgang Denk Wrote:
>> 
>>> In message <200710131722183904740@gmail.com> you wrote:
>>>> Signed-off-by: Lucas Jin <lucasjin@gmail.com>
>>>>
>>>> --- ./drivers/rtl8139.c.orig	2007-10-12 22:17:52.000000000 +0800
>>>> +++ ./drivers/rtl8139.c	2007-10-13 17:34:40.117515408 +0800
>>> Could you please explain which problem this patch is supposed to fix?
>> 
>> The rtl8139 specification says the configuration registers can be accessed through PCI memory mapping or PCI IO mapping.
>> 
>> The u-boot driver uses PCI memory mapping, but it doesn't work, so I changed it to PCI IO mapping.
>
>On my target RTL8139 or its variant works fine without such a change.
>Why do you think doesn't work? Could you elaborate please?

When I used PCI memory mapping to access rtl8139 configuration registers, like MAC0-MAC05, the CPU paniced,
as I described in the subject "a problem about rtl8139 driver on sandpoint8245board" I proposed Sep. 30th 2007.

After changing to PCI IO mapping, the problem was solved.
>
>> The driver of rtl8139 in Linux Kernel also uses PCI IO mapping to access the configuration registers. 
>
>Do you mean CONFIG_8139TOO_PIO?

I don't what you mean by  CONFIG_8139TOO_PIO, there is not such a define in U-Boot.
>
>thanks,
>
>    Shinya



------------------		
Thanks		 
Lucas Jin

[U-Boot-Users] [patch] rtl8139.c: use PCI IO map

[Masami Komiya]

Dear Lucas,

I used RTL8139 driver on MPC8241 board. It works fine.
The followings are defined in the configuration file.

/* PCI memory */
#define CFG_IBAT2L      (0x80000000 | BATL_PP_10 | BATL_CACHEINHIBIT)
#define CFG_IBAT2U      (0x80000000 | BATU_BL_256M | BATU_VS | BATU_VP)

#define CFG_DBAT2L      CFG_IBAT2L
#define CFG_DBAT2U      CFG_IBAT2U

/* PCI Stuff */
#define CONFIG_PCI
#define CONFIG_PCI_PNP

#define CONFIG_NET_MULTI

#define CONFIG_RTL8139
/* for RTL8139 */
#define KSEG1ADDR(x)     ({u32 _x=le32_to_cpu(*(u32 *)(x)); (&_x);})
#define _IO_BASE         0x00000000

The result of pci command are

# pci
Scanning PCI devices on bus 0
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
_____________________________________________________________
00.00.00   0x1057     0x0006     Bridge device           0x00
00.0c.00   0x10ec     0x8139     Network controller      0x00
		:

# pci header 00.0c.00
   vendor ID =                   0x10ec
   device ID =                   0x8139
   command register =            0x0007
   status register =             0x0290
   revision ID =                 0x20
   class code =                  0x02 (Network controller)
   sub class code =              0x00
   programming interface =       0x00
   cache line =                  0x08
   latency time =                0x20
   header type =                 0x00
   BIST =                        0x00
   base address 0 =              0x00000001
   base address 1 =              0x80000000
   base address 2 =              0x00000000
   base address 3 =              0x00000000
   base address 4 =              0x00000000
   base address 5 =              0x00000000
   cardBus CIS pointer =         0x00000000
   sub system vendor ID =        0x11ec
   sub system ID =               0x8139
   expansion ROM base address =  0x00000000
   interrupt line =              0xff
   interrupt pin =               0x01
   min Grant =                   0x20
   max Latency =                 0x40

Masami Komiya

[U-Boot-Users] [patch] rtl8139.c: use PCI IO map

[Scott Wood]

On Sun, Oct 14, 2007 at 09:12:11AM +0800, Lucas Jin wrote:
> When I used PCI memory mapping to access rtl8139 configuration registers,
> like MAC0-MAC05, the CPU paniced, as I described in the subject "a problem
> about rtl8139 driver on sandpoint8245board" I proposed Sep. 30th 2007.

Sounds more like a problem with PCI setup, than with the driver or the
hardware.

-Scott

[U-Boot-Users] [patch] rtl8139.c: use PCI IO map

[Lucas Jin]

Masami Komiya Wrote:

Yes, you are right, I didn't configurated my board correctly.

>Dear Lucas,
>
>I used RTL8139 driver on MPC8241 board. It works fine.
>The followings are defined in the configuration file.
>
>/* PCI memory */
>#define CFG_IBAT2L      (0x80000000 | BATL_PP_10 | BATL_CACHEINHIBIT)
>#define CFG_IBAT2U      (0x80000000 | BATU_BL_256M | BATU_VS | BATU_VP)

The former developer of my project changed the two defines above to 

#define CFG_IBAT2L	(0x78000000 | BATL_PP_10 | BATL_CACHEINHIBIT) 
#define CFG_IBAT2U	(0x78000000 | BATU_BL_128K | BATU_VS | BATU_VP)

and I didn't realize that.

>
>#define CFG_DBAT2L      CFG_IBAT2L
>#define CFG_DBAT2U      CFG_IBAT2U
>
>/* PCI Stuff */
>#define CONFIG_PCI
>#define CONFIG_PCI_PNP
>
>#define CONFIG_NET_MULTI
>
>#define CONFIG_RTL8139
>/* for RTL8139 */
>#define KSEG1ADDR(x)     ({u32 _x=le32_to_cpu(*(u32 *)(x)); (&_x);})
>#define _IO_BASE         0x00000000
>
>The result of pci command are
>
># pci
>Scanning PCI devices on bus 0
>BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
>_____________________________________________________________
>00.00.00   0x1057     0x0006     Bridge device           0x00
>00.0c.00   0x10ec     0x8139     Network controller      0x00
>		:
>
># pci header 00.0c.00
>   vendor ID =                   0x10ec
>   device ID =                   0x8139
>   command register =            0x0007
>   status register =             0x0290
>   revision ID =                 0x20
>   class code =                  0x02 (Network controller)
>   sub class code =              0x00
>   programming interface =       0x00
>   cache line =                  0x08
>   latency time =                0x20
>   header type =                 0x00
>   BIST =                        0x00
>   base address 0 =              0x00000001
>   base address 1 =              0x80000000
>   base address 2 =              0x00000000
>   base address 3 =              0x00000000
>   base address 4 =              0x00000000
>   base address 5 =              0x00000000
>   cardBus CIS pointer =         0x00000000
>   sub system vendor ID =        0x11ec
>   sub system ID =               0x8139
>   expansion ROM base address =  0x00000000
>   interrupt line =              0xff
>   interrupt pin =               0x01
>   min Grant =                   0x20
>   max Latency =                 0x40
>
>Masami Komiya
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>U-Boot-Users mailing list
>U-Boot-Users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users



------------------		
Thanks		 
Lucas Jin