4.x+RID - support

[NutKase]

true enough, feel free to type up a paragraph on using bootpage and I'll stuff it in the post when I get the chance. (short on time right now, stepping out the door)

Oh crap, Riley
------------------------
Everyone. I posted hastily then thought it was better as a pm. Here's the post again for clarification and I'll try to help with a 'Using bootpage paragraph' as so politely suggested as soon as I get the chance.



--------------Original post-------------------------
I'm really not trying to be confrontational here but, I don't get it. My position has always been to learn something if you wanted more (i.e a hacked system) than TiVo provided at purchase...

I've wanted people to learn and have a baseline of knowledge (so they can help themselves later and save ddb the trouble) in order to try/apply new methods/hacks.

I've tried to post 'knowledge' and 'understanding' type posts to this effect.

Now:

dd if=/tivo/vmlinux.px of=/dev/hdc3
dd if=/tivo/vmlinux.px of=/dev/hdc6
*puts the killhdinitrd'd kernel in BOTH kernel partitions.
one's not necessary but it saves having to check which with bootpage


...one's not necessary but it saves having to check which with bootpage

What?

Do we now, not even want people to know what status their tivo is in?

Maybe all we want them to do is be able to use the latest hack without knowing anything?

I don't like it.

I do, however, like the... 'nsts-framework install succeeds only after you successfully answer a few questions' suggestion.


NutKase
-----End Original Post-----------------


Note to self: Don't be so quick to post - .

[alldeadhomiez]

1. Why is the brcmdrv-rb.o included in 011_uma6fix.init when rc.sysinit will try to load it again?

The new dssapp requires that brcmdrv-rb.o is loaded before it is started. The old one was not as picky.

If the blank screen bothers you, you can add something like:

/tvbin/osdwriter /tvbin/PromScreen2Version7.NTSC.png

after loading brcmdrv-rb.o. Or, you can change rc.arch so that brcmdrv-rb.o is loaded right before dssapp starts. This was presumably omitted from the framework because it is a more invasive (and less intuitive) change.

2. Is the absence of parameters going to cause problems?

Unlikely, but if you do have video issues it is something to keep in mind.

[chrised]

The new dssapp requires that brcmdrv-rb.o is loaded before it is started. The old one was not as picky.

Hmm... Just realized why my "hacked by hand" version worked. When I was trying to figure this out (before the release) I had modified rc.sysinit to load the dssapp later, just like 3.1.1x does.

Out of curiousity, I did try the original 4.x dssapp and the 3.1.1x dssappAV. Neither worked, so clearly the modified dssapp is critical to this package.

Do we know much about the dssapp included in this package? ie, what version it came from "before modifications"?

I'm surprised we lose the ability to view the access card number with it (on the system info page).

[Chainsaw76]

Ok, I have 4.x running on my Hughes sd-dvr80. But I cant get telnet working, and I dont have a Serial BASH cable. Im using a Linksys USB200m.

I added the following lines to rc.sysinit.author

#!/bin/bash

ifconfig eth0 192.168.1.201 broadcast 192.168.1.255 netmask 255.255.255.0
route add default gw 0.0.0.0 netmask 0.0.0.0 metric 1

sleep 15

tnlited 23 /bin/bash -login &

My log says

eth0: unknown interface.

[update: I just now got the Green screen of death.Took about 30 min to resolve.. Still cant access the network though.]

[update: It works! Hint: Make sure the USB adaptor hasnt pulled it's self free while you were pulling the drive.]

-Jason

[hxmiller]

I followed the directions and everything worked great (expect missing local which was easy to fix).

I'm not sure however if the 3.1.1c killhdinitrd kernel I used from PTV is a LBA48 kernel.

Here's what I did.

- Used InstantCake to restore a 4.0.1b image
- dd'd a 3.1.1.c kernel
- copied the init framework files
- replaced dssapp
- clear and delete


thoughts?

thanks.

Seems that it didn't monte. See bash output below. TWP reports the kernel is 2.4.18 however I don't have to full capacity of the drive. Something is strange. However the good news is I can telnet, ftp, extract using tytools, TWP. I must be tired cause I'm sure the answer is staring me in the face.


## MIPS ## arch-specific shell functions defined
starting test.conf
starting /init/001_bash.init
starting /init/010_lba48.init
didn't monte, booting normally
starting /init/011_uma6fix.init
bash: no job control in this shell
loading uma6fix.o
bash-2.02# uma6fix v0.9.0 Copyright (C) 2004 CRS (Riley Cassel)
Development by HD TeAm and others
REDISTRIBUTION OF THIS PROGRAM OR ANY DERIVED WORK IN ANY FORM IS PROHIBITED.
ADDITIONAL TERMS APPLY. Please read the supplied documentation for details.
uma6fix: ready and waiting
finished uma6fix.sh

[hxmiller]

Anyone else seeing slower network access under 4.0 than under 3.1.1c.

I'm showing a couple of "unaligned access" in the kernel when the usb drivers load. Also link is established at half-duplex.



Nov 19 03:28:07 (none) kernel: usb-ohci.c: USB OHCI at membase 0xb4000000, IRQ 5
Nov 19 03:28:07 (none) kernel: usb-ohci.c: usb-00:0d.0, PCI device 1033:0035
Nov 19 03:28:08 (none) kernel: usb.c: new USB bus registered, assigned bus number 1
Nov 19 03:28:08 (none) kernel: hub.c: USB hub found
Nov 19 03:28:08 (none) kernel: hub.c: 3 ports detected
Nov 19 03:28:08 (none) kernel: Unaligned Access to 0x82b53723 in kernel mode at 0xc0138680
Nov 19 03:28:08 (none) kernel: Unaligned Access to 0x82b53723 in kernel mode at 0xc0138694
Nov 19 03:28:09 (none) kernel: usb-ohci.c: USB OHCI at membase 0xb4001000, IRQ 3
Nov 19 03:28:09 (none) kernel: usb-ohci.c: usb-00:0d.1, PCI device 1033:0035
Nov 19 03:28:09 (none) kernel: usb.c: new USB bus registered, assigned bus number 2
Nov 19 03:28:09 (none) kernel: hub.c: USB hub found
Nov 19 03:28:09 (none) kernel: hub.c: 2 ports detected
Nov 19 03:28:09 (none) kernel: Unaligned Access to 0x82b53983 in kernel mode at 0xc0138680
Nov 19 03:28:09 (none) kernel: Unaligned Access to 0x82b53983 in kernel mode at 0xc0138694
Nov 19 03:28:09 (none) kernel: hub.c: new USB device 00:0d.0-1, assigned address 2
Nov 19 03:28:09 (none) kernel: usb.c: USB device 2 (vend/prod 0x77b/0x2226) is not claimed by any active driver.
Nov 19 03:28:09 (none) kernel: PokeFirewallPort: Poking hole through firewall at port 2190, protocol udp
Nov 19 03:28:09 (none) kernel: iptables: No chain/target/match by that name
Nov 19 03:28:09 (none) kernel: PokeFirewallPort: Poking hole through firewall at port 2190, protocol tcp
Nov 19 03:28:09 (none) kernel: iptables: No chain/target/match by that name
Nov 19 03:28:09 (none) kernel: usb.c: registered new driver ax8817x
Nov 19 03:28:10 (none) kernel: ax8817x.c: ASIX AX8817x USB Ethernet driver v1.0.0
Nov 19 03:28:11 (none) kernel: ax8817x.c: eth0: Link established, half duplex, flow control disabled

[chrised]

Seems that it didn't monte. See bash output below.
starting /init/001_bash.init
starting /init/010_lba48.init
didn't monte, booting normally
starting /init/011_uma6fix.init

Is this output from the serial port? If so, look back further in the output and you'll see you really did monte. If you're looking in the logs, I believe the logs never show output from the original kernel.

If you look at 010_lba48.init:

#!/bin/bash

# put the lba48 kernel for your sys in /init ( 3.x - 2.4.4 or 4.x - 2.4.18 )
if [ "$lba48" != "true" ]; then
 bootparm=$(/sbin/bootpage -p /dev/hda)
 /sbin/insmod -f /init/kmonte.o
 /init/monte /init/vmlinux.px "$bootparm lba48=true"
 echo "monte failed - starting bash on the serial port"
 while true; do /bin/bash -login</dev/ttyS2&>/dev/ttyS2; sleep 5; done
fi

echo "didn't monte, booting normally"

You'll see that on the second pass through (when you monte'd into the 2.4.18 kernel), it does that last echo which might mislead you to think the monte failed.

TWP reports the kernel is 2.4.18 however I don't have to full capacity of the drive.

Riley's tool for automatically reclaiming the missing space hasn't been released yet.

If you want to reclaim that space now, you'll need to boot the drive in a LBA48 mfstools disk and run mfsadd to get it.

[hxmiller]

[QUOTE=chrised]Is this output from the serial port? If so, look back further in the output and you'll see you really did monte. If you're looking in the logs, I believe the logs never show output from the original kernel.

If you look at 010_lba48.init:

[CODE]

I see that now. Now back to work on the network performance.

starting /init/010_lba48.init
bash-2.02# monte: Two-kernel Monte for MIPS (Version 0.1)
monte: MuscleNerd (MIPS version), Erik Arjan Hendriks (x86 version)
monte: loaded kernel image (target load_addr=0x80002000, len=0x166e60) at 0x83ea0000
monte: total pages used: 360 for image, 2 for indirect tables, 1 for reload code
Loading R5432 MMU routines.
CPU revision is: 00005430
Primary instruction cache 32kb, linesize 32 bytes.
Primary data cache 32kb, linesize 32 bytes.
Linux version 2.4.18 (root@localhost) (gcc version 3.0) #1 Mon Oct 18 17:27:26 CDT 2004

[hxmiller]

Riley's tool for automatically reclaiming the missing space hasn't been released yet.

If you want to reclaim that space now, you'll need to boot the drive in a LBA48 mfstools disk and run mfsadd to get it.

MFSAdd reported that there was nothing to add. Total was 147 hours. If my drive is 160gb is that the best I'll do.

[ronnythunder]

yes, 147 is about right for a 160. i have a "small 160" that has 144 hours.

ronny

[chrised]

MFSAdd reported that there was nothing to add. Total was 147 hours. If my drive is 160gb is that the best I'll do.

A Seagate 120 gig drive is only good for 105 hours. So, you've got an additional 42 hours from the 40 extra gigs. Seems quite reasonable.

[w2kr]

I've just spent a bit of time searching and can't find an answer to this. Is it okay to let TiVo dial home for the first time to get through the TiVo guided setup or am I supposed to run some tcl script to do this for me?

[AhoyMatey]

I've just spent a bit of time searching and can't find an answer to this. Is it okay to let TiVo dial home for the first time to get through the TiVo guided setup or am I supposed to run some tcl script to do this for me?

MuscleNerd said somewhere that it's ok.

When I was playing with putting 4.0.1b on an hdvr earlier this week, I ran fakecall/fixsub, and after a reboot didn't have to do the guided setup.

[Chainsaw76]

Alright, I followed the original instructions using a tdc2400080 image I found hosted on an FTP site. (No instant cake). And everything worked. There were a few hickups, and unexpected bumps, and one big USER error. And I hope by describing them I'll ease someones pain.

• I tried MFS Restore from this image to my Original 80gig (from a huges sd-dvr80). I know I shouldn't use the original, but I have an Idenitcal working drive in an identical machine, and I backed this drive up when I first got it (virgin state). I kept getting an error saying the drive was too small! (I also tried Instant cake, and it gave the same answer). So I had to hand restore the image with dd.
  
• I decided to reboot my PC after loaded the image just in case linux needed a chance to reload the partition table. I dont kow if it helped or not, but it's quick painless, and I'm a linux novice.
  
• Followed the rest of the directions. tried to get fancy with rc.sysinit.author and install my network drivers.
  
• The clear and delete all takes a while (took the better part of an hour).
  
• I had to pull the drive several times trying to get networking set up.. Problem was.. USB cable was unplugged (I didnt notice till I went to check to see if the lights were lit).
  
• On one reboot (after the last time I pulled the drive) I got the green screen of death.. I started to panic, searched DD, and decided to let it go.. it cleared in 30 minutes.
  
• You wont have local channels. they came back over night w/o me doing anything.
  
• Tivo function didnt work (recording shows, etc) I ran superpatch4all, and seperately fixsub.. still didnt work.. Untill I did a reboot. That made everythign work, no call needed (in fact, I couldn't call. just flat out didnt work).
  
• After the post superpatch for all reboot, everything works perfectly. I dont have MRV working yet (Still need to set up my second machine), but Listening to music, and all tivo functions work 100%).

Second machine gets hacked tonight.. Thank you to everyone who helped put this together, and to fellow bounty contributers.

-Jason

[NutKase]

Alright, I followed the original instructions using a tdc2400080 image I found hosted on an FTP site.

What tivo software version was this?


NutKase