PDA

View Full Version : Uma6 RID on 4.x Thinktank



Soopaman
11-04-2004, 02:37 AM
This thread is only to discuss what has, and hasn't worked when trying to attempting to develop a 4.x RID solution. Please respect my wishes and keep this thread any personal "opinions", "theories" and mud-slinging, because we only have a few days left to prove we can beat the bounty. ;)

Soopaman
11-04-2004, 02:59 AM
I have tried this method with no success.

Without using SetTivoConfig (search forums for background on this method), tivoconfig.o was unable recognize the board, and the kernel was not set up to properly handle the hardware's memory settings (could use a custom kernel, but you'd end up with the same problems as below).

When using SetTivoConfig, the modules 5.x load, but when attempt to use any 4.x application that interacts with the hardware, the application fails miserably and system crashes (due to the different structure of the modules - look at the kernel's headers to read more on).

Soopaman
11-04-2004, 03:31 AM
Hit and miss, but I think this is the best/only method that warrants effort.

Without SetTivoConfig, the machine fails miserably at the 4.x tivoconfig.o module (similar to using the first 3.x S2 dtivo software on a uma6).

With SetTivoConfig, the system loads i2c and other modules properly, with all other minor applications properly interacting with the system's hardware. The only problem comes when loading the brcmdrv-rb.o modules loads where the error message given is "No such device" when hitting the init_module function within the kernel.

When using a boardID spoofed by SetTivoConfig, the uma4 hardware init values work properly for all the non- audio/visual modules. Which leads me to believe that only the tivoconfig.o and brcmdrv-rb.o modules need to be patched. tivoconfig.o either requires an addition to the listed boardid's that jumps back to using uma4's init values, while brcmdrv-rb.o needs some minor tweaking to properly init the RID hardware. The best place that I think to start looking for patch points, is to compare the non-rid and rid 3.x software modules versions. Since 4.x came out before RID hardware, it's header structure seemed almost equivalent to the non-RID 3.x software; where adding functionality would be a matter of understanding what compiled module code to add.

Soopaman
11-04-2004, 03:40 AM
Didn't test to much with it because I was already sick of testing and wanted to enjoy my tivo.

Non-RID 3.x
Without SetTivoConfig - never tried
With SetTivoConfig - never tried

RID 3.x
Without SetTivoConfig - I believe I tried to boot it once, and had problems with using 4.x applications with due to the modules slightly different structure. Should be great place to start playing around, but I don't have too much time lately.

With SetTivoConfig - never tried, probably should have given it a shot though.

alldeadhomiez
11-04-2004, 10:28 AM
tivoconfig.o just provides a trivial character device interface to the GetTivoConfig/SetTivoConfig kernel functions (in linux/arch/mips/tivo). I highly doubt that it needs to be patched.

nova1
11-04-2004, 03:51 PM
Hit and miss, but I think this is the best/only method that warrants effort.

With SetTivoConfig, the system loads i2c and other modules properly, with all other minor applications properly interacting with the system's hardware. The only problem comes when loading the brcmdrv-rb.o modules loads where the error message given is "No such device" when hitting the init_module function within the kernel.

The module is probably getting the chip device id and version # and comparing it to a list of known chips and then returning -ENODEV if not found. Maybe you can patch the routine to look for the correct chip id. Do you have a list of the broadcom chips and what is compatible with what? Maybe you can use one that is close. In the disassembly, I've seen comparisons to numbers that look like chip ids. I don't have RID hardware. Good luck.

Woody Allen
11-07-2004, 04:04 AM
Could someone with a 3.x RID DTivo do a "ls -l /dev" capture it as a text file and post it.

I want to compare the Major/Minor device numbers of the broadcomm driver to that of a standard 4.x running on my HDVR2.

Also, If someone could post the dmesg when you "insmod -f brcmdrv-rb.o" and the system crashes. Does the module load? Does the Tivo crash when tivoapp starts. Please post your dmesg. You should use the SetTivoConfig as described above before loading.

Thanks, I don't have a RID unit but I would like to help solve this problem.

EvilJack
11-07-2004, 07:03 AM
Could someone with a 3.x RID DTivo do a "ls -l /dev" capture it as a text file and post it.


here are the 'important ones...' from a 3.1.1c RID tivo.



crw-rw-rw- 1 0 0 90, 10 Feb 11 2004 mswitch4v
crw-rw-rw- 1 0 0 90, 6 Feb 11 2004 mswitch4a
crw-rw-rw- 1 0 0 90, 9 Feb 11 2004 mswitch2v
crw-rw-rw- 1 0 0 90, 17 Feb 11 2004 mswitch2e
crw-rw-rw- 1 0 0 90, 5 Feb 11 2004 mswitch2a
crw-rw-rw- 1 0 0 90, 8 Feb 11 2004 mswitch0v
crw-rw-rw- 1 0 0 90, 16 Feb 11 2004 mswitch0e
crw-rw-rw- 1 0 0 90, 4 Feb 11 2004 mswitch0a
crw-rw-rw- 1 0 0 90, 0 Feb 11 2004 mswitch0
crw-rw-rw- 1 0 0 1, 100 Feb 11 2004 console
crw-rw-rw- 1 0 0 91, 0 Feb 11 2004 tivoconfig
crw-rw-rw- 1 0 0 96, 0 Feb 11 2004 oslink2
crw-rw-rw- 1 0 0 95, 0 Feb 11 2004 oslink
crw-rw-rw- 1 0 0 90, 20 Feb 11 2004 mswitch0vsync
crw-rw-rw- 1 0 0 90, 28 Feb 11 2004 mswitch0vbi
crw-rw-rw- 1 0 0 90, 28 Feb 11 2004 mswitch0i
crw-rw-rw- 1 0 0 99, 0 Feb 11 2004 i2c
crw-rw-rw- 1 0 0 97, 0 Feb 11 2004 fan
crw-rw-rw- 1 0 0 96, 2 Feb 11 2004 dtune2
crw-rw-rw- 1 0 0 95, 2 Feb 11 2004 dtune
crw-rw-rw- 1 0 0 96, 7 Feb 11 2004 ddl2
crw-rw-rw- 1 0 0 95, 7 Feb 11 2004 ddl
crw-rw-rw- 1 0 0 96, 3 Feb 11 2004 cam2
crw-rw-rw- 1 0 0 95, 3 Feb 11 2004 cam
crw-rw-rw- 1 0 0 96, 1 Feb 11 2004 apg2
crw-rw-rw- 1 0 0 95, 1 Feb 11 2004 apg
crw-rw-rw- 1 0 0 105, 0 Feb 11 2004 vsched0
crw-rw-rw- 1 0 0 108, 0 Feb 11 2004 ppp
crw-rw-rw- 1 0 0 127, 2 Feb 11 2004 mixaud2
crw-rw-rw- 1 0 0 127, 1 Feb 11 2004 mixaud1
crw-rw-rw- 1 0 0 127, 0 Feb 11 2004 mixaud0
crw-rw-rw- 1 0 0 101, 0 Feb 11 2004 kfir
crw-rw-rw- 1 0 0 102, 0 Feb 11 2004 input
crw-rw-rw- 1 0 0 103, 1 Feb 11 2004 cobra1
crw-rw-rw- 1 0 0 103, 0 Feb 11 2004 cobra0
crw-rw-rw- 1 0 0 30, 7 Feb 11 2004 brcmvid
crw-rw-rw- 1 0 0 30, 4 Feb 11 2004 brcmrec
crw-rw-rw- 1 0 0 30, 5 Feb 11 2004 brcmplay
crw-rw-rw- 1 0 0 30, 3 Feb 11 2004 brcmmgs
crw-rw-rw- 1 0 0 30, 6 Feb 11 2004 brcmdma
crw-rw-rw- 1 0 0 30, 0 Feb 11 2004 brcm0
crw-rw-rw- 1 0 0 30, 2 Feb 11 2004 bcmpcm
crw-rw-rw- 1 0 0 30, 1 Feb 11 2004 bcmgfx
crw-rw-rw- 1 0 0 30, 54 Feb 11 2004 psirec1
crw-rw-rw- 1 0 0 30, 44 Feb 11 2004 psirec
crw-rw-rw- 1 0 0 30, 31 Feb 11 2004 pespvr
crw-rw-rw- 1 0 0 30, 42 Feb 11 2004 pesaudio
crw-rw-rw- 1 0 0 30, 53 Feb 11 2004 brcmrecdata1
crw-rw-rw- 1 0 0 30, 43 Feb 11 2004 brcmrecdata
crw-rw-rw- 1 0 0 30, 52 Feb 11 2004 brcmrec1
crw-rw-rw- 1 0 0 30, 15 Feb 11 2004 brcmpcm2
crw-rw-rw- 1 0 0 30, 14 Feb 11 2004 brcmpcm1
crw-rw-rw- 1 0 0 30, 51 Feb 11 2004 besstartcode1
crw-rw-rw- 1 0 0 30, 41 Feb 11 2004 besstartcode
crw-rw-rw- 1 0 0 30, 50 Feb 11 2004 besrec1
crw-rw-rw- 1 0 0 30, 40 Feb 11 2004 besrec
crw-rw-rw- 1 0 0 30, 30 Feb 11 2004 bespvr
crw-rw-rw- 1 0 0 30, 16 Feb 11 2004 bcmpax
crw-rw-rw- 1 0 0 30, 17 Feb 11 2004 mp2
crw-rw-rw- 1 0 0 30, 18 Feb 11 2004 ac3
crw-rw-rw- 1 0 0 127, 0 Feb 11 2004 ircatch0
crw-rw-rw- 1 0 0 126, 0 Feb 11 2004 irblast0
lrwxrwxrwx 1 0 0 6 Feb 11 2004 mpeg0v -> pespvr
lrwxrwxrwx 1 0 0 8 Feb 11 2004 mpeg0a -> brcmplay

nova1
11-07-2004, 12:33 PM
Remember the fun is in the journey.

I don't have a RID unit. I believe we want to use the 3.1.1c driver as that has code to handle the new chip. So gather all the appropriate tools(tmesis/drnull's disassembler script, IDA, cross-compiler). I believe you have to document the user/ABI interface by looking at the disassembly and looking at the ioctl() calls to major devno 30 devices from tivoapp and dssappAV. This will be useful in developing a veneer driver. In the 3.1.1c driver, it makes a call to register_chrdev(30,"bcm7030stb",&fops). One possibility for the veneer driver is to register using major devno 30 and patch the original driver to register under 31 and have the veneer driver call the real driver.

Good luck.

Woody Allen
11-07-2004, 12:48 PM
here are the 'important ones...' from a 3.1.1c RID tivo.


Thanks for posting these. However, there seem to be some important ones missing.

Would you kindly post the entire list.

Thanks

jteloh
11-07-2004, 03:01 PM
Thanks for posting these. However, there seem to be some important ones missing.

Would you kindly post the entire list.

Thanks
Here is from a 3.1.1e rid unit

Woody Allen
11-07-2004, 05:54 PM
The 4.x /dev contains the following special device file that 3.x does not contain:



104, 0 Jun 12 2004 router_client

EvilJack
11-07-2004, 06:01 PM
The 3.x /dev posted above contains the following special device file that 4.x does not contain:



104, 0 Jun 12 2004 router_client




...huh.... which post has a /dev/router_client?

jack

Woody Allen
11-07-2004, 06:19 PM
Actually, I messed up my printouts of the two - they look almost identical.

4.x has the /dev/router_client

Here is the 4.x /dev listing:

chrised
11-07-2004, 11:57 PM
Actually, I messed up my printouts of the two - they look almost identical.

4.x has the /dev/router_client

Here is the 4.x /dev listing:

One of the differences between 3.1.1 and 4.0 is this section of rc.arch:

function loadRouter () {
/sbin/insmod /lib/modules/router.o
}

I would expect that this device is created by this module.

I'm very skeptical that the broadcom driver cares about the router config.

Woody Allen
11-08-2004, 02:50 AM
The only problem comes when loading the brcmdrv-rb.o modules loads where the error message given is "No such device" when hitting the init_module function within the kernel.

My understanding is that "init_module" is a function defined in the device driver (module) that gets called when the module gets loaded.

A major number gets assigned to the device by calling the following from within init_module:


int register_chrdev(unsigned int major, const char *name,
struct file_operations *fops);



So if the node file in /dev was missing or was incorrect, the "init_module" function might return the "No such device" error.

The module has to initialize other resources (memory & io ports). I wonder how the module knows the io port & memory addresses - though these should not change because the module works on the hardware, just under a different kernel. We know that they are not passed in when loaded (although some buffer size and playback parameters are), so the IO address is either hard coded or it gets it how???

Tiros
11-12-2004, 10:28 PM
Want to read & write physical memory?
Heres a little something that may help:

http://www.lart.tudelft.nl/lartware/port/devmem2.c

rc3105
11-13-2004, 12:47 AM
Want to read & write physical memory?
Heres a little something that may help:

http://www.lart.tudelft.nl/lartware/port/devmem2.c
too funny (http://www.dealdatabase.com/forum/showpost.php?p=79185&postcount=1)

AlphaWolf
11-13-2004, 03:17 PM
Hmm....Interesting thread, what routes/attempts have you guys taken so far?

I have been looking at the differences in how the software treats RID vs non RID units to get 5.x working on them (albeit there isn't as much work required as with 4.x, although I have been analyzing the differences between the two versions) I might be able to help a bit.

AlphaWolf
11-14-2004, 04:14 PM
Hmm...I take it that nobody has gone anywhere beyond poking around the kernel memory then? AFAICT the kernel issues should be the most trivial part of this.

Soopaman
11-15-2004, 02:55 AM
I think my patch for the 4.x kernel get's me to the same place that SetTivoConfig did on a RID box, where all modules apps load and report properly except for brcmdrv-rb. Will know for sure after re-build my cc environment and the kernel.

In other news, I just read over a conversation between dubbya and alphawolf on another thread, and wondered how on would go about cleanly splicing these patches into a killhdinitrd'd kernel. Any ideas?

rc3105
11-15-2004, 08:31 AM
...and wondered how on would go about cleanly splicing these patches into a killhdinitrd'd kernel. Any ideas?
you can't splice anything into a killhdinitrd'd kernel, it wouldn't pass the prom signature verification ;)


edit: course, that's what was said about the original signed kernels too, killhdinitrd illustrates one "impossible" method. this week's homework is to list 3 others

The Only Druid
11-15-2004, 08:44 AM
you can't splice anything into a killhdinitrd'd kernel, it wouldn't pass the prom signature verification ;)

So, you're suggesting though that perhaps if you did splice this onto a kernal, you'd have to monte in order to use it [on a RID unit]?

(I'm a touch out of my element in this thread, since I'm not capable of this programming, but at least this question seems reasonable)

rc3105
11-15-2004, 09:03 AM
killhdinitrd isn't actually spliced into the kernel, it's spliced into a tiny portion of the kernel partition that isn't signature checked. it's not a kernel exploit, it's a prom exploit that has has the overall effect of neutering the initrd

while this is somewhat off topic, it is relevant to the whole theme in that sometimes if you can't seem to find an answer, maybe you're asking the wrong question

Woody Allen
11-15-2004, 10:13 PM
I haven't had much time to try things out lately, but I have had some thoughts. There is more than one way to approach this problem.

a) Make 4.x Tivoapp & modules run on a "fixed" kernel.

b) Make the 3.x brdcm-drv-rb.o module run on 4.x.

c) Make 4.x Tivoapp run on a 2.4.20 kernel

Possible means of acheiving them are:

Comparing the 2.4.4 & 2.4.18 kernel sources and locating the differences. A little more difficult to compare the modules without source, but they could be disassembled.

A module that acts as a wedge could be written and weged in front of the other modules. Logging and comparasion of working versus non working versions could yeild the differences.

For "c", disassembling of tivoapp and strace of working versus non-working tivoapp versions could yield the differences.

"c" is my choice because all the modules already load, the latest tivo kernel is used, and you don't necessairly have to enter kernel space to debug.

When I have some time, I will purse "c".