[Solved] TC3.8_4 Real Time Upgrade

[MTCAT]

Hi Rich,

Okay, thanks will do. I'll continue playing around with the boot-up thing, regarding modprobe though, should I worry about it, or just use insmod ?

For modprobe, it seems I need to get I 24dsi.ko added into /lib/modules/2.6.33.3-l1.rt19/modules.dep.

Maybe I need to manually put 24dsi.ko in /lib/modules/2.6.33.3-l1-rt19/kernel, and then run "sudo depmod -a", to get 24dsi.ko added to /lib/modules/2.6.33.3-l1.rt19/modules.dep ??

Or, can I put a line in modules.dep myself, like, /lib/modules/2.6.33.3-l1-rt19/kernel/24dsi.ko ?

Thanks,

David

[Rich]

Hi MTCAT
I'm sure we covered this before. What did we do in the non real time kernel?

Did we add this to bootlocal.sh:

Code: [Select]

cp -a /home/tc/PATH/TO/24dsi.ko /lib/modules/2.6.33.3-l1-rt19/kernel
depmod -a
Or did we copy it to a directory under kernel and back it up:

Code: [Select]

sudo mkdir /lib/modules/2.6.33.3-l1-rt19/kernel/drivers/dsi
cp -a /home/tc/PATH/TO/24dsi.ko /lib/modules/2.6.33.3-l1-rt19/kernel/drivers/dsiThen add  lib/modules/2.6.33.3-l1-rt19/kernel/drivers/dsi  to  /opt/.filetool.lst
Add  depmod -a  to  bootlocal.sh.
And run a backup:

Code: [Select]

filetool.sh -b
You might also want to review what changes we made to the  start  script and where you were calling it from.

[Rich]

Hi MTCAT

... Or, can I put a line in modules.dep myself, like, /lib/modules/2.6.33.3-l1-rt19/kernel/24dsi.ko ?

No no no. That's what  depmod -a  is for.

[MTCAT]

Hi Rich,

I'm probably wrong, but as I recall, manually typing "sudo modprobe 24dsi.ko" would work with the non-RT kernel, we only had issues with modprobe (with the non RT kernel) when we were trying to auto-load the 24dsi.ko module at boot time, that's when we had to comment out a few lines in the GSC start script (an if-fi structure that checked for the module existence - we commented that out).

So we kind of did your second option below, but only when we made the extension ? In /home/tc, we did "mkdir -p package/usr/local/lib/modules/2.6.33.3-tinycore/kernel/drivers/24dsi", and then;

cp 24dsi.linux.4.11.91.32.0/24dsi/lib/lib24dsi_api.so package/usr/local/lib
cp 24dsi.linux.4.11.91.32.0/24dsi/driver/24dsi.ko package/usr/local/lib/modules/2.6.33.3-tinycore/kernel/drivers/24dsi

And then we also copied the executable test programs into package/usr/local/bin with a big fancy command that copied files of the same name as the directory they are located in.
 
But that was all for making the extension I thought, and modprobe worked prior to that, at least manually ("sudo modprobe 24dsi.ko).

I'll study my "Where to build ADC module" printout (small textbook ) some more at work tomorrow, maybe I'm forgetting something.

Thanks,

David

[Rich]

Hi MTCAT
Yeah, I remember that now. By making an extension out of those files some housekeeping gets handled for you just by
loading the extension.  tce-load  knows there's a kernel module present so it runs  depmod -a  and  udevadm trigger.
It also runs  ldconfig  so the system can find the library (lib24dsi_api.so).

Didn't we also copy the  start  script into the extension after making some changes? I seem to recall telling you to
alter the name (start_24dsi ?) because  start  was too generic.

If you copy the non real time extension to your  /home/tc  directory, you can unpack it and check what's inside:

Code: [Select]

unsquashfs -d NonRT ExtensionName-2.6.33.3.tczThe contents can be found in  NonRT.

[MTCAT]

Hi Rich,

Finally had a chance to look at my printout, the only big difference I can see is that initially I was trying to build the 24dsi driver on the non RT install in /usr/src/linux/drivers, but then I switched over to building the driver in /home/tc, whereas in the RT case, I just started off building the driver in /home/tc.

Regarding the start program, we made a directory called ~/package/usr/local/bin and put it in there as "start24dsi", of course, to get "start24dsi" to work, we had to comment out those 5 lines in the script that checked for module existence.

So I don't think I'm any further ahead really, I still don't know why "sudo modprobe 24dsi" doesn't work in the RT case (no 24dsi link in modules.dep), yet modprobe did work (when typing it out manually) in the non-RT case, the regular non-modified GSC start script using "insmod" works though in the RT case...

But after loading the driver with "insmod", with the GSC "start" script,  on the RT kernel, I still don't see any 24dsi listing in modules.alias or modules.dep, the commands below return nothing, "grep 24dsi /lib/modules/2.6.33.3-l1-rt19/modules.dep", "grep 24dsi /lib/modules/2.6.33.3-l1-rt19/modules.alias", "modprobe -l 24dsi", "which start" "modinfo 24dsi.ko" does work, but only in when in the directory ~/24.dsi.linux.4.11.91.32.0/24dsi/driver.

Should I worry about getting modprobe to work on the RT install ?, or just make an extension this time using the GSC "start" script as-is, using insmod ?, it seems to work, not sure if "insmod" could be a problem in some way down the road ?

Thanks,

David

[MTCAT]

Hi Rich,

Check this out, "nonrt.txt" contains the output of "sudo find / -name 24dsi.ko" for the non RT kernel, note the last line in "nonrt.txt", how did that get there ? I'm assuming that's what we need and where we need it for modprobe ?

I also attached the same thing for the RT kernel, "rt1.txt" is before running "sudo ./start", and "rt2.txt" is after loading 24dsi.ko by running "sudo ./start", there's no difference and the driver file isn't where it's needed for modprobe ?

I'm not sure, hopefully this gives you some clues.

Thanks,

David

[Rich]

Hi MTCAT

... But after loading the driver with "insmod", with the GSC "start" script,  on the RT kernel, I still don't see any 24dsi listing in modules.alias or modules.dep, ...

That's because  insmod  doesn't update  modules.alias  or  modules.dep , depmod  does.

[Rich]

Hi MTCAT

Check this out, "nonrt.txt" contains the output of "sudo find / -name 24dsi.ko" for the non RT kernel, note the last line in "nonrt.txt", how did that get there ? ...

It came from the first line in that file:

Code: [Select]

/tmp/tcloop/24dsi-2.6.33.3-tinycore-686/usr/local/lib/modules/2.6.33.3-tinycore/kernel/drivers/24dsi/24dsi.koThat's the extension you made containing the driver, library, sample programs, and the start24dsi script.

...  I'm assuming that's what we need and where we need it for modprobe ? ...

Yes.

You need to package the driver, library, sample programs, and the start24dsi script.
These 2 posts covered that:
http://forum.tinycorelinux.net/index.php/topic,24795.msg157885.html#msg157885
http://forum.tinycorelinux.net/index.php/topic,24795.msg157950.html#msg157950
Change  2.6.33-tinycore  to  2.6.33.3-l1-rt19.
Copy the modified  start24dsi  script to  package/usr/local/bin.

This is where you finally got it working:
http://forum.tinycorelinux.net/index.php/topic,24795.msg158234.html#msg158234

[MTCAT]

Hi Rich,

Thanks, okay, I'll just go ahead and build the extension around the start24dsi script using modprobe, with that if-fi commented out, and hope that it all works, I'm just still wondering why modprobe isn't working with the RT install even when doing it manually, hopefully tce-load will take care of it all I guess ! Will give it a try.

Thanks,

David

[Rich]

Hi MTCAT
modprobe should work if you:

Code: [Select]

sudo mkdir -p /usr/local/lib/modules/2.6.33.3-l1-rt19/kernel/drivers/dsi/

Code: [Select]

sudo cp -a 24dsi.ko  /usr/local/lib/modules/2.6.33.3-l1-rt19/kernel/drivers/dsi/

Code: [Select]

sudo depmod -a

[MTCAT]

Hi Rich,

Thanks alot, I'll see if I can get modprobe to work manually first before building the extension, hopefully today, thanks a lot.

Cheers,

David

[MTCAT]

Hi Rich,

After following your instructions in reply 175 I was able to load the 24dsi module with modprobe !, thanks !

I then went ahead and made the extension file system with the modified start script, I got it all to work now ! !, auto-loading with the RT kernel !!, thanks again for all your help !

I did have some confusion with bootlocal.sh though, two things;

1) Are there actually two copies of bootlocal.sh ? One in /opt and another in /mnt/sdb1/opt ? I was initially editing the latter as that's what was in my notes, adding in the /usr/local/bin/start24dsi command to that file, but then I reverted to editing the one in /opt in the end ?
2) I was editing bootlocal.sh but then not doing a b/u, so on re-boot, the old bootlocal.sh (w/o the start24dsi command) would overwrite the new one !

I forgot about this need to do a b/u and was confused how my bootlocal.sh was getting changed when I'm using a persistent /opt !

Anyway, I did a b/u with "filetool,sh -b", but then re-named "mydata.tgz" to "rtmydata.tgz", to avoid what happened before, with the b/u overwriting my already persistent data, is that okay ?, I think we did that before, or would it be better to do the backup and then just use "norestore" boot code ?
 
The system is still a but flakey on boot-up though, it's spinning it's wheels doing something of which I'm not sure, I'm hoping it has something to do with chrony or gpsd, those packages are installed and being loaded, but I don't have the GPS hooked up yet with the RT kernel, so maybe that's giving the OS a problem, it's looking for the GPS that isn't there, and it does so until it times out or something. I may just try removing those extensions from onboot.lst and see if that changes anything.

Thanks,

David

[Rich]

Hi MTCAT

... 1) Are there actually two copies of bootlocal.sh ? One in /opt and another in /mnt/sdb1/opt ? ...

No, there are not.  /mnt/sdb1/opt  is a persistent directory that resides on your storage device. That directory gets
mounted in the root file system as  /opt.

... 2) I was editing bootlocal.sh but then not doing a b/u, so on re-boot, the old bootlocal.sh (w/o the start24dsi command) would overwrite the new one !

I forgot about this need to do a b/u and was confused how my bootlocal.sh was getting changed when I'm using a persistent /opt ! ...

We covered this. Remove  opt  and  home  from  /opt/.filetool.lst.  Then do this:

Code: [Select]

sudo touch /tmp/dummy
sudo echo "tmp/dummy" >> /opt/.filetool.lst
filetool.sh -b

[MTCAT]

Hi Rich,

Thanks for your (incredible) patience...I'll do the empty file b/u method again, I won't ask again !

Now that I have the 24DSI driver being auto-loaded, I took a crack at using syslog again to see where the system is spinning it's wheels during boot, the only thing that jumps out at me is a 33 second time period between 20:01:05 and 20:01:38 (line 574 to 575) when root is running "/usr/local/bin/touch /etc/sysconfig/newmodules" , this happens right at the end of loading all the extensions from /mnt/sdb1/tce/optional (the 24DSI driver is the last extension to be loaded right now).

Attached the file here. Does that 33 second time period seem okay to you ? Root is creating an empty file in /etc/sysconfig called newmodules and that takes 33 seconds ?

I also removed the loading of ntp, chrony and gpsd extensions but that didn't speed up the boot process that I could tell.

Thanks,

David