> Subject: Re: [ivtv-users] cx18 module causes freeze after kernel upgrade > From: [email protected] > To: [email protected] > CC: [email protected] > Date: Sat, 26 Jan 2013 09:40:29 -0500 > > On Fri, 2013-01-25 at 15:17 -0500, Kyle Lil wrote: > > > > So, unfortunately, I am getting a ton of errors as previously > > described in this thread > > (http://www.gossamer-threads.com/lists/ivtv/users/40784?do=post_view_flat#40784) > > with the stock kernel driver. Just to be sure I'm not overdoing things > > here, is there a way I can set the .qam_gain parameter without hard coding > > a new value in cx18-dvb.c and building a custom media-tree kernel? > > You have at least two options (but first make a backup copy of your > stock cx18.ko module): > > 1. Download the Ubuntu source package for the exact Ubuntu kernel you > are running, make the needed edit in cx18-dvb.c, follow Ubuntu's > instructions for rebuilding the kernel package from souce, and use the > cx18.ko module from the newly built kernel source. > > or > > 2. Edit the cx18.ko oject with a binary editor: > > a. Make a backup! > > $ su - root > > # cd /lib/modules/.../kernel/drivers/media/.../cx18 > > # cp cx18.ko cx18.ko.stock > > b. Figure out where .qam_gain is stored in the file > > # objdump -h -j .data cx18.ko > cx18.ko: file format elf64-x86-64 > > Sections: > Idx Name Size VMA LMA File > off Algn > 16 .data 0000051c 0000000000000000 0000000000000000 > 0002a580 2**5 > CONTENTS, ALLOC, LOAD, RELOC, DATA > File offset of initialized .data section ---------------------------^^^^^^^^ > > # objdump -t -j .data cx18.ko | grep hauppauge_hvr1600_tuner > 00000000000003a0 l O .data 0000000000000020 > hauppauge_hvr1600_tuner > Offset in .data ^^^ > Length in .data ---------------------------------^^ > > > c. Do some hexadecimal number math to convert everything to file offsets: > > # echo "obase=16; ibase=16; 2A580 + 3A0" | bc > 2A920 > > # echo "obase=16; ibase=16; 2A580 + 3A0 + 20" | bc > 2A940 > > > d. Display the data bytes in the structure using cx18.ko file offsets: > > # objdump -s -j .data --start-address=0x2a920 --stop-address=0x2a940 > --adjust-vma=0x2a580 cx18.ko > > cx18.ko: file format elf64-x86-64 > > Contents of section .data: > 2a920 63000000 a0175200 0024f400 01030101 c.....R..$...... > 2a930 01000000 c8000000 fc000000 01000200 ................ > For me, .qam_gain is at offset 0x2a93e ---^^ > > e. Compare with source code in cx18-dvb.c: > > # vim -R /blah/blah/blah/cx18-dvb.c > ... > static struct mxl5005s_config hauppauge_hvr1600_tuner = { > .i2c_address = 0xC6 >> 1, /* 0x63 */ > .if_freq = IF_FREQ_5380000HZ, /* 0x5217a0 */ > .xtal_freq = CRYSTAL_FREQ_16000000HZ,/* 0xf42400 */ > .agc_mode = MXL_SINGLE_AGC, > .tracking_filter = MXL_TF_C_H, > .rssi_enable = MXL_RSSI_ENABLE, > .cap_select = MXL_CAP_SEL_ENABLE, > .div_out = MXL_DIV_OUT_4, > .clock_out = MXL_CLOCK_OUT_DISABLE, > .output_load = MXL5005S_IF_OUTPUT_LOAD_200_OHM, /*0xc8*/ > .top = MXL5005S_TOP_25P2, /* 0xfc */ > .mod_mode = MXL_DIGITAL_MODE, > .if_mode = MXL_ZERO_IF, > .qam_gain = 0x02, > .AgcMasterByte = 0x00, > }; > ... > > f. Patch the .qma_gain byte and inspect that the patch was correct: > > # echo "2a93e: 01" | xxd -r - cx18.ko > > # objdump -s -j .data --start-address=0x2a920 --stop-address=0x2a940 > --adjust-vma=0x2a580 cx18.ko > > cx18.ko: file format elf64-x86-64 > > Contents of section .data: > 2a920 63000000 a0175200 0024f400 01030101 c.....R..$...... > 2a930 01000000 c8000000 fc000000 01000100 ................ > Changed .qam_gain at offset 0x2a93e -----^^ > > > The above is really a pain, but it takes less time then recompiling a > kernel. I'm sure you could write a Perl script to do all of the above, > if you think you will have to do this often. > > Regards, > Andy > Thanks, Andy. It looked a little daunting, but I ended up going with option 2. Thanks to your instructions, everything actually went quite smoothly and I was able to get the binary modified in just a few minutes. Not sure if I'll have to do it often, but I guess every time I update the kernel? Maybe I'll avoid doing that when possible... Thanks again for the help, Kyle
_______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
