rt2570 on TiVo Series 2 NEC R5432 MIPS big-endian

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

I'm in the process of trying to get the rt2570 driver working on a Tivo Series 2 Stand-Alone unit which is a NEC R5432 MIPS running Linux 2.4.20.

Starting with the latest CVS as of yesterday, I hacked a few things in order to get the driver to compile and recognize the device. However, after the few adjustments, once I ifconfig the rausb0 interface, the TiVo starts spewing lines like this non-stop:

Code:

Unaligned Access to 0x80d43076 in kernel mode at 0xc021cd8c
Unaligned Access to 0x802d704a in kernel mode at 0xc021b3dc
Unaligned Access to 0x802d704a in kernel mode at 0xc021b408
Unaligned Access to 0x802d704a in kernel mode at 0xc021dc2c

There's a bunch of different addresses that show up as it scrolls by.

I made this change to rt_config.h --

Code:

#if defined(__BIG_ENDIAN) || defined(__BIG_ENDIAN__) || \
        defined(_BIG_ENDIAN) || defined(__ARMEB__) || defined(__MIPSEB__)

(added the "|| defined(__MIPSEB__)" to the end)

I made this change to rtusb_main.c --

Code:

        for (i = 0; i < rtusb_usb_id_len; i++)
        {
#ifdef __MIPSEB__
                if (dev->descriptor.idVendor == rtusb_usb_id[i].idVendor &&
                        dev->descriptor.idProduct == rtusb_usb_id[i].idProduct)
#else
                if (le16_to_cpu(dev->descriptor.idVendor) == rtusb_usb_id[i].idVendor &&
                        le16_to_cpu(dev->descriptor.idProduct) == rtusb_usb_id[i].idProduct)
#endif
                {

Without that change, it wouldn't detect the device (always saying "Device Descriptor not matching").

Any chance there's still interest in working on this driver to get it working on big-endian MIPS? I'm sure there will be many happy TiVo owners who would love to see this work done.

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

So, I built the rt2570 with symbols, and was able to track one of the unaligned accesses back to sanity.c:PeerBeaconAndProbeRspSanity(). Specifically:

Code:

    498     // get timestamp from payload and advance the pointer
    499     memcpy(Timestamp, Ptr, TIMESTAMP_LEN);
    500     Ptr += TIMESTAMP_LEN;
    501 
    502     // get beacon interval from payload and advance the pointer
    503     *BeaconPeriod = le16_to_cpup((PUSHORT)(Ptr));
    504     Ptr += 2;

The assembly for this:

Code:

/home/dossy/src/rt2570-cvs-2008102616/Module/sanity.c:499
   2b810:       8fa20078        lw      v0,120(sp)
   2b814:       8ac40018        lwl     a0,24(s6)
   2b818:       9ac4001b        lwr     a0,27(s6)
   2b81c:       8ac5001c        lwl     a1,28(s6)
   2b820:       9ac5001f        lwr     a1,31(s6)
   2b824:       a8440000        swl     a0,0(v0)
   2b828:       b8440003        swr     a0,3(v0)
   2b82c:       a8450004        swl     a1,4(v0)
   2b830:       b8450007        swr     a1,7(v0)
/home/dossy/src/linux-2.4/include/linux/byteorder/swab.h:165
   2b834:       96c20020        lhu     v0,32(s6)
   2b838:       304300ff        andi    v1,v0,0xff
   2b83c:       00031a00        sll     v1,v1,0x8
   2b840:       00021202        srl     v0,v0,0x8
   2b844:       00621825        or      v1,v1,v0
/home/dossy/src/rt2570-cvs-2008102616/Module/sanity.c:503
   2b848:       8fa20070        lw      v0,112(sp)
   2b84c:       a4430000        sh      v1,0(v0)

Specifically, the trap happens at 2b834:

Code:

2b834: 96c20020 lhu v0,32(s6)

Here's the relevant lines from swab.h:

Code:

    163 static __inline__ __u16 __swab16p(__u16 *x)
    164 {
    165         return __arch__swab16p(x);
    166 }

I'm going to keep digging, but maybe this will make a lot of sense to Vern or someone else as to why this is resulting in an Unaligned Access trap.

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

Getting some help from folks in #tivohelp on freenode IRC, I added a simple printk() to sanity.c to check to see if either of the pointers are halfword aligned, and I got this:

Code:

rt2570: <-- RTUSBBulkReceive: PendingRx=8 of 8, NextRxIndex=2
rt2570: BeaconPeriod = 0x80539e68, Ptr = 0x80210d39
Unaligned Access to 0x80210d39 in kernel mode at 0xc0217904
Unaligned Access to 0x80210d3b in kernel mode at 0xc021791c
rt2570: - PeerBeaconAndProbeRspSanity - unrecognized EID = 47 Len = 1: 04

Yup, Ptr isn't halfword aligned. Ugh. :-)

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

Here's another place in the code where an alignment issue popped up:

Code:

   1713                         pRxD = (PRXD_STRUC)(pData + pRxContext->pUrb->actual_length - sizeof(RXD_STRUC));
   1714                         flipRxDescriptor(pRxD);

That flipRxDescriptor() is interesting:

Code:

    514 static inline void flipRxDescriptor(
    515                 IN      PRXD_STRUC      pRxD)
    516 {
    517         le32_to_cpus((u32 *)(pRxD));
    518 
    519 } /* End flipRxDescriptor () */

What's the right solution, here? I'd hate to double-copy buffers just to align them for this platform, but these byteorder swapping macros need to be used on properly aligned addresses.

Help? Somebody? Anybody? :-)

This seems like a systematic problem ...

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

Also, loading the driver results in a kernel panic after 10-15 seconds. Here's some of the kernel log leading up to it, then the panic:

Code:

Unaligned Access to 0x813c7076 in kernel mode at 0xc021d978
Unaligned Access to 0x813c7076 in kernel mode at 0xc021d74c
Unaligned Access to 0x813c7076 in kernel mode at 0xc021b568
Oops in /build/sandbox-b-7-2-2-mr-release-mips-other/b-7-2-2-mr/os/linux-2.4/arc
h/mips/mm/fault.c::do_page_fault, line 395:
$0 : 00000000 9001fc00 ffffffff 4f505152 4f505152 fffffffe 8052cdb3 8052cd94
$8 : ffffffff 0000000a 00000000 8052cdc8 00000000 00000000 fffffffb ffffffff
$16: 801609c7 80160db7 00000019 8052cd98 4f505152 ffffffff 801609b8 00000400
$24: 0000000a 00000000                   8052c000 8052cd10 00000002 8012cddc
Hi : 00000833
Lo : 33333a60
epc  : 8012bf44    Tainted: P
Status: 9001fc02
Cause : 00000008
Process rausb0-Cmd (pid: 361, stackpage=8052c000)
Stack:    4748494a 4b4c4d4e 4f505152 53545556 5758595a 0000003c 8052cdc7
 8052ce3f 00000000 9001fc01 0000000b 0000000b 00000002 00000000 0000000a
 00000000 80020844 c01ec0c0 0000000a ffffffff 8052cdb3 00000002 00000000
 80220160 00000000 80220160 0000000b 0000000b 00000002 00000000 0000000a
 c01ec0c0 4c6f7720 4f505152 c021edb7 53545556 5174795b 35345d3d 30205045
 523d3025 ...

Trace: 8012bf44 8012cddc 80020844 c01ec0c0 c01f0bc0 c01efad8 c01ec868 (Bad trace
)
Code: 2402ffff  10a2000b  00801821 <80820000> 10400008  00000000  2406ffff  24a5
ffff  10a60004
rt2570: --->RTUSBBulkRxComplete status=0 len=134 PendingRx=7
rt2570: --->RTUSBBulkRxComplete status=0 len=90 PendingRx=6
rt2570: --->RTUSBBulkRxComplete status=0 len=134 PendingRx=5
Kernel panic: Die called

 Core of 0 bytes written
Panic logged

Edit: This appears to be a bad call to rt2570_dbgprint (0xc01ec070) from PeriodicExec (0xc01f0150).

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

The latest status: I can load the rt2570 module, I've reduced the number of unaligned accesses (I had to add 3 bytes of padding to the RX_CONTEXT struct) and the kernel panic has gone away for now.

I've compiled wireless-tools 29 and loaded it up on the TiVo. It seems like it's working but doesn't actually work:

Code:

$ iwconfig rausb0
Warning: Driver for device rausb0 recommend version 16 of Wireless Extension,
but has been compiled with version 14, therefore some driver features
may not be available...

rausb0    RT2500USB WLAN  ESSID:"Panoptic"  Nickname:"TiVo"
          Mode:Managed  Frequency=2.412 GHz  Bit Rate=11 Mb/s
          RTS thr:off   Fragment thr:off
          Encryption key:off
          Link Quality=0/100  Signal level:-120 dBm  Noise level:-99 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

$ iwlist rausb0 scan
Warning: Driver for device rausb0 recommend version 16 of Wireless Extension,
but has been compiled with version 14, therefore some driver features
may not be available...

rausb0    No scan results

$ dmesg
rt2570: <-- rtusb_ioctl_giwrange
rt2570: ==> rtusb_ioctl_siwscan
rt2570: MlmeEnqueue, num=3
rt2570: <== rtusb_ioctl_siwscan started
rt2570: rtusb_ioctl_giwscan. 0 BSS returned

So, at this point, I'm guessing that some of the messing around I did in order to eliminate the unaligned accesses has caused the driver to stop operating correctly. Any tips on what debugging information to look at to try and figure out where?

Vern · **Posted:** Tue Oct 28, 2008 3:36 pm

Hi dossy,

Well, you're doing a lot of work here. It looks like one big problem is alignment requirements.

If you look in rtmp_type.h, you'll see a macro called ALIGN_USB_RCV. Could you try changing things so that that's turned on and see what happens? The general approach is to identify structure members with platform-specific alignment requirements and use that macro, or something like it, on them.

Also, it would be very helpful if you could provide a sorted list of gcc's predefined constants for your target environment: e.g. (all one line)

Code:

touch /tmp/dummy_file.c; gcc -E -dM /tmp/dummy_file.c;\rm /tmp/dummy_file.c)|sort|gzip ><choose-a-name>.gz

Then attach the gzipped file to a post here. That will give me information I need to handle any additional MIPS requirements.

Thanks,

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

Vern wrote:

If you look in rtmp_type.h, you'll see a macro called ALIGN_USB_RCV. Could you try changing things so that that's turned on and see what happens? The general approach is to identify structure members with platform-specific alignment requirements and use that macro, or something like it, on them.

Thank you for looking at this, Vern! I'll experiment with ALIGN_USB_RCV to 4 bytes as MIPS wants word alignment and uses 32-bit words.

Vern wrote:

Also, it would be very helpful if you could provide a sorted list of gcc's predefined constants for your target environment: e.g. (all one line)

Code:

touch /tmp/dummy_file.c; gcc -E -dM /tmp/dummy_file.c;\rm /tmp/dummy_file.c)|sort|gzip ><choose-a-name>.gz

Then attach the gzipped file to a post here. That will give me information I need to handle any additional MIPS requirements.

You got it - see attached.

Vern · **Posted:** Tue Oct 28, 2008 7:44 pm

Hi dossy,

According to the constants you supplied, it looks like you're using GCC 3, which is a little old. Before proceeding further, you might try upgrading to gcc 4.1 (not 4.2, there's a big fat warning in the 2.4 kernel source about that).

After doing so, you may find there are kernel compile problems. To fix them try this patch.

Thanks,

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

I can try to build a GCC 4.1 MIPS cross-compiler, but I'm hoping that isn't the root cause of all the issues I'm having - do you think it really could be?

Also, the patch you attached only updates the i386 kernel bits - not the mips stuff. I don't think that patch would be of much use for me, right?

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

SUCCESS!

The rt2570 driver is compiled and working with minimal unaligned access traps on my TiVo Series 2 SA MIPS box. I'm attaching my patch against rt2570-cvs-2008102616.

If you wouldn't mind reviewing it and letting me know what you think, I'd really appreciate it. Thanks.

Vern · **Posted:** Fri Oct 31, 2008 5:19 pm

Hi dossy,

Thanks for your efforts and investigation. A large part of the fixes you've created in your patch apply to all the legacy drivers; so you're really providing a benefit here.

The changes to rt_config.h and rtmp_type.h are needed and you should be seeing them soon in the hourly tarballs.These fixes also apply to the other legacy drivers and you'll see them show up in them shortly as well.

The other changes are confusing to me. They all seem to be doing a "shift and or" operation that does basically the same thing that "le16_to_cpu" does when expanded in a big endian environment. That expansion is determined entirely by the gcc build environment, *not* by anything defined during the driver's make process. If le16_to_cpu & co. are not doing their job, I think something more serious is awry that needs to be fixed; so I think we need to look into this part some more before putting anything in CVS.

Re. rtusb_main.c:
The free_netdev change causes a compile error under 2.4.36. As of 2.4.23 at least, free_netdev does exist. So I think the proper thing to do here is to add a conditional to rt_config.h to provide it if compiling for a kernel earlier than the earliest 2.4 series kernel in which it does exist. It would be great if you could download and grep the 2.4.21 and 2.4.22 patch files to find out. On my system, free_netdev is defined in <souce-path>/include/linux/netdevice.h.

Thanks again,

dossy · **Joined:** Mon Oct 27, 2008 3:49 am **Posts:** 13

Vern,

Thanks for reviewing the patch!

The byte-swapping macros compile down to lw/sw and lhu/shu MIPS assembly which requires word and half-word aligned addresses. The data structures in the rt2xxx drivers aren't aligned properly in many cases, so what I did was force unoptimized byte-swapping which doesn't trigger the unaligned access traps. (The unoptimized byte-swapping is still orders of magnitude faster than triggering repeated unaligned access traps, trust me.)

I'll try to identify which Linux kernel version introduced free_netdev and adjust the patch accordingly.

Thanks!

Vern · **Posted:** Sun Nov 02, 2008 4:21 pm

Hi dossy,

Mmm. Vern do some googling. Vern start to understand. Looks like an alignment trap is not really a failure; it's just the mips way of handling a 16(32) bit access aligned on an 8(16) bit boundary. Is that right?

Anyway, looking at the ptr value you printed in the sanity check routine, I found a likely candidate for the cause in the MLME_QUEUE structure alignment. Could you try the attached patch on a vanilla copy of the latest CVS and see if it reduces the number of alignment faults?

Thanks,

pthomas · **Joined:** Tue Nov 11, 2008 5:07 pm **Posts:** 7

I'm also trying to get the driver to work on a MIPS processor (micronas 7108). I'm using a 2.6.12 source tree and gcc 3.3.4, and I can't easily move to a newer kernel. The 1.1.0-b2 version of the driver compiles fine and I can load the rt2570.ko module, and I can see the device in iwconfig. The problem is when I issue the "ifconfig rausb0 up" command I get "RTUSB --> NICInitTransmit" from the debug and then I keep getting "--->USB_ResetDevice" messages.

I downloaded the rt2570-csv-2008111110 csv version and applied the patch posted on this thread rt2570-tivo-mips.patch, but the module won't compile. I get the the following error "rtusb_main.c:1468: error: too few arguments to function `try_to_freeze'"

thanks,
Paul

rt2x00.serialmonkey.com

Forum rules

rt2570 on TiVo Series 2 NEC R5432 MIPS big-endian

Who is online