PDA

View Full Version : RID Units ( Hughes SD-DVR40 ) and user compiled Kernels.



EvilJack
09-12-2004, 10:10 AM
I've been stuck for a week trying to get a custom compiled kernel working on my new Hughes SD-DVR40 ( a RID unit ) and I'm stuck.

( this is kind of a follow on to the S2 Kernel thread, but it
is RID unit oriented )

I'm down to a basic question...
Does anyone have a 2.4.4-TiVo-3.0 based kernel that they copiled from source and patches that works on a RID based tivo?

I've used the sources/patches/buildscript ( posted in the
S2 Kernel thread) to make my kernel. I've tried my kernel
on 2 different Tivos ( same models ) and I've tried a kernel
that someone else gave me and none of them finish booting.
I've made several posts in the S2 Kernel thread and haven't gotten the 'fix' yet....

So... I'm down to the basic question...
Does anyone have a 2.4.4-TiVo-3.0 based kernel that they copiled from source and patches that works on a RID based tivo... or an I the first person to try this ( which I find hard to believe )

If someone can tell me were a good,working, custom compiled kernel is ( 2.4.4 ) that runs on a RID unit, I'd
like to try it ( to make sure it works on my RID unit ) and I'd like to know how it was built.

It could be that my kernel is ok.. but the way I start it is hosed...
/sbin/insmod -f /lib/modules/kmonte.o
sleep 1
/devbin/monte /vmlinux.px root=/dev/hda7 dsscon=true console=2,115200 upgradesoftware=false Reboot=no
but no one has said anything about this method only
partially working. with this, the tivo boots and starts
the custom kernel... it just hangs before it finishes running
the rc.sysinit startup script.

Thanks - jack

alldeadhomiez
09-12-2004, 11:35 AM
There's no real difference on these units. The main things you have to watch out for are:

1. that the initial boot kernel and the new kernel both support your board in tivoconfig.h (based on your logs the new kernel did).

2. that the OS supports your board.

Since the tivo.com kernel sources were updated with Uma6 support long before the units hit store shelves, I would guess that any custom public 2.4.4 kernels support the Uma6 boards. Obviously the signed 3.1.1c kernel does as well.

Also, if you're doing anything funny before you run monte, like installing other kernel modules, don't. monte doesn't reset all of the hardware, and neither does the kernel.

MatthewSeidl
09-13-2004, 11:38 PM
I'd be really interested in the answer as well. I've got my S4040R booting with a killhdinitrd kernel and monte'ing to something else, but I lack a something else that makes me happy (specifically LBA48 support). I'd love to know if its the RIDness of my unit thats screwing me up, or if I've done something else broken.

EvilJack
09-14-2004, 11:11 AM
I'd be really interested in the answer as well. I've got my S4040R booting with a killhdinitrd kernel and monte'ing to something else, but I lack a something else that makes me happy (specifically LBA48 support). I'd love to know if its the RIDness of my unit thats screwing me up, or if I've done something else broken.

I haven't had time to re-do my stuff... Currently... I did a full boot/reboot
using sleepers stuff with his monte code on partition 16. I loaded all
of the USB drivers and tivo stuff and was up and running... watching TV.

I would then telnet or access the serial console and load the
kmonte.o module and run my monte a 2nd time to load my
custom kernel. This may be the problem. I need to re-load my
drive and start over I think...

jack

alldeadhomiez
09-14-2004, 12:07 PM
I would then telnet or access the serial console and load the
kmonte.o module and run my monte a 2nd time to load my
custom kernel. This may be the problem. I need to re-load my
drive and start over I think...

As I said before, do not load any other kernel modules between a reset and an invocation of monte, unless you know what you're doing. That includes network drivers. monte does not implement most of the hardware initialization code found in the PROM.

Also, you should isolate whether the problem is with your newly built kernel or with your procedure, by running replace_initrd against a known good 3.1.1c kernel and then trying to chain load it.

EvilJack
09-14-2004, 12:19 PM
As I said before, do not load any other kernel modules between a reset and an invocation of monte, unless you know what you're doing. That includes network drivers. monte does not implement most of the hardware initialization code found in the PROM.

Also, you should isolate whether the problem is with your newly built kernel or with your procedure, by running replace_initrd against a known good 3.1.1c kernel and then trying to chain load it.


I read what you said... just haven't time to try it again... the poster asked
my what I was doing and I told him...

I was going to isolate my issue last night but my AC was out and it
was 90 in my computer room and I gave up. I powered everything off
and rand throught the sprinklers with the kids. ;)

jack

MatthewSeidl
09-14-2004, 12:27 PM
As I said before, do not load any other kernel modules between a reset and an invocation of monte, unless you know what you're doing. That includes network drivers. monte does not implement most of the hardware initialization code found in the PROM.


So, if I'm reading this right, the correct sequence is

Boot -> load kmonte.o -> monte -> boot second kernel -> load various network drivers

Correct?

w2kr
09-14-2004, 12:46 PM
So, if I'm reading this right, the correct sequence is

Boot -> load kmonte.o -> monte -> boot second kernel -> load various network drivers

Correct?I recommend this (http://www.dealdatabase.com/forum/showthread.php?t=37570) thread to help you through this.

EvilJack
09-15-2004, 10:05 AM
Just wanted to say I got my kernel working on my RID
unit. ( See the above referenced thread )

This thread can be deleted / marked dead. I don't
think it serves a useful purpose any more....

jack

MatthewSeidl
09-15-2004, 11:58 AM
Yep. I have a custom LBA48 kernel running on my S4040R RID unit right now. Too many of these threads are filled with old (and thus confusing) info. Shut'er down.