[Solved] TC3.8_4 Real Time Upgrade

[MTCAT]

Hi Rich,

That command returns

#define UTS_RELEASE "2.6.33.3-rt19"

Should be 2.6.33.3-l1-rt19 I guess...

Thanks,

David

[Rich]

Hi MTCAT

...  I'm pretty sure I used the wrong config file, ...

Did you use the config file you created for the RT kernel you built instead of this one:
http://repo.tinycorelinux.net/3.x/contrib/rt-kernel/src/config-2.6.33.3-l1-rt19

If that's the case, you may have to rerun Juanitos instructions:
http://forum.tinycorelinux.net/index.php/topic,24944.msg159183.html#msg159183

You could try correcting it in  /lib/modules/2.6.33.3-l1-rt19/build/include/generated/utsrelease.h , though I have no idea
if that will work.

[MTCAT]

Hi Rich,

Sorry this is confusing, when I refer to using the wrong config file, I'm talking about the "DIY" RT build that I attempted some time ago. For that I used, "wget http://tinycorelinux.net/3/x/release/src/kernel/config-2.6.33.3-tinycore".

I think that was wrong, and maybe this is the source of all the problems with the "DIY" RT build ?

For the "pre-built" RT kernel, to make the patched RT module directory to compile against, and to make the symbolic link too, I did use the config file you correctly linked me to.

I just was thinking I should have used this "RT" config file you linked me to for the DIY RT kernel build too, I could try to do the "DIY" RT kernel build again with the correct config file, just not sure if there are other mistakes in my list (reply 119).

Will see if modprobe 24dsi.ko --force-vermagic works to load the driver in the pre-built RT kernel.

Thanks,

David

[MTCAT]

Hi Rich,

The --force-vermagic doesn't seem to be a valid option with modprobe in TC3.8.4, and "-f" with insmod didn't work either, there's my big contribution .

But, typing "sudo editor utsrelease.h", and changing "2.6.33.3-rt19" to "2.6.33.3-l1-rt19", and then running "sudo ./make_all clean" in ..../24dsi/driver, followed by "sudo ./make_all" worked !, the 24dsi.ko driver was built and inserted !, "lsmod" shows "24dsi" there, and I can now run the 24dsi test programs !

Since my RT patched linux-2.6.33.3 directory (what I'm symlinking too) is in home, the changes to utsrelease.h should be persistent too, so that's nice.

So this looks to be a valid work-around, thanks so much, do you think this is okay to go forward with though ?, or should I still try to re-do the DIY RT kernel ?, if the latter worked okay, would seem to be less hoops to jump through, "cleaner".

Thanks,

David

[Rich]

Hi MTCAT

... So this looks to be a valid work-around, thanks so much, do you think this is okay to go forward with though ? ...

Since the module loads and the test programs work it is probably OK.

, or should I still try to re-do the DIY RT kernel ?, if the latter worked okay, would seem to be less hoops to jump through, "cleaner".

I looked through the patch and config files and didn't see the  l1  part of the version string being added. I did see the patch
changing the  EXTRAVERSION =  line from  .3  to .3-rt19  in the top level  Makefile.  You can see it like this:

Code: [Select]

head /lib/modules/2.6.33.3-l1-rt19/build/Makefile
If you want to fix it, I would say just rebuild the headers like Juanito described:
http://forum.tinycorelinux.net/index.php/topic,24944.msg159183.html#msg159183
After you apply the patch, edit:

Code: [Select]

/home/tc/linux-2.6.33.3-patched/Makefileand change the  EXTRAVERSION =  line from  .3-rt19  to .3-l1-rt19

Then continue until you get to  make modules. Make sure the  Makefile  still has  EXTRAVERSION = .3-l1-rt19.
If all is good, run  make modules  and wait for it to complete.

[Rich]

Hi MTCAT
When it's done, check that  utsrelease.h  contains the correct value.

[MTCAT]

Hi Rich,

Thanks, maybe I'll leave my current working 2.6.33.3-l1-rt19 install as is, and on the next installation (I hope to build 5 or 6 of these loggers), I'll modify the Makefile as you suggest and see if that does the trick !

Thanks again, now I can make the squashfs extension and get the auto-loading going, get chrony fired up, and the last challenge will be to compile the data acquisition program and get it going !

Thanks,

David

[MTCAT]

Hi Rich,

As you know, I unpacked linux-2.6.33.3-patched.tbz2 in /home/tc, does it make sense that having this big directory full of stuff would slow down booting up ?

Right now, after the empty backup file gets loaded, the little VortexDX3 takes quite a time (1 minute or so) to actually get into FLWM.

Thanks,

David

[Rich]

Hi MTCAT

... does it make sense that having this big directory full of stuff would slow down booting up ? ...

Your home directory is persistent so nothing in it should be getting backed up. So the answer is it shouldn't slow you down.

What does this show:

Code: [Select]

cat /opt/.filetool.lst
Add the boot code  syslog  to your  extlinux.conf file. It goes on the line that contains the word  quiet.
After FLWM comes up:

Code: [Select]

cp /var/log/messages messages.txtAttach  messages.txt  to your next post.

[MTCAT]

Hi Rich,

Thanks for the help, files2.txt contains the output of "cat /opt/.filetool.lst" and messages.txt contains the output from syslog.

Thanks,

David

[Rich]

Hi MTCAT
You have  home  listed in  /opt/.filetool.lst.

Check your  extlinux.conf  file. Does the entry you are booting to have  home=UUID=...  similar to this:

Code: [Select]

LABEL realtime
KERNEL /boot/bzImageRT1
APPEND initrd=/boot/tinycoreRT1.gz quiet waitusb=5:UUID="622fa3dd-62bb-43fc-a837-43021b9b3c7f" tce=UUID="622fa3dd-62bb-43fc-a837-43021b9b3c7f" home=UUID="622fa3dd-62bb-43fc-a837-43021b9b3c7f" opt=UUID="622fa3dd-62bb-43fc-a837-43021b9b3c7f"
If it does, then after  FLWM  comes up, remove  home  from  /opt/.filetool.lst  and do this:

Code: [Select]

filetool.sh -bThen reboot and it should start faster.

[MTCAT]

Hi Rich,

I do have persistent home and opt setup (as you showed me long ago) in extlinux.conf, so I removed "home" from /opt/.filetool.lst and ran "filetool.sh -b", unfortunately it didn't seem to help, seems to be something else, right before FLWM starts up I see some things flash by, will try to capture that on my iPhone.

And annoyingly, I can't load the 24dsi.ko module with modprobe anymore, I get an error, "modprobe: module 24dsi.ko not found in modules.dep".

I did run "sudo depmod -a" again but that didn't help, sorry about this, just never seems to go smoothly. I don't think the symbolic link has to be there for modprobe to load the 24dsi.ko module ?

"sudo insmod 24dsi.ko" still works to load the module though, so that's something at least....

I'm leery to nuke my already built and insertable module but maybe I just need to run "sudo ./make_all clean" and "sudo ./make_all" again ?

Party never ends, on power-down I'm also seeing a new message;

sd 0:0:0:0: [sda] Stopping disk ACPI: Preparing to enter system sleep state S5
Power down

Not sure why that popped up now...sorry for all these questions and problems, sda5 (128 GByte CF card) is not even mounted, so....

Thanks,

David

[Rich]

Hi MTCAT

... so I removed "home" from /opt/.filetool.lst and ran "filetool.sh -b", unfortunately it didn't seem to help, ...

Check  /opt/.filetool.lst  and make sure it still does not contain  home.

[MTCAT]

Hi Rich,

"home" is indeed absent from /opt/.filetool.lst.

I do notice that there's some Adobe Flash related stuff, and Opera related stuff in /opt/.xfiletool.lst ?, I think those are both web browser related ?, which I certainly don't need, not sure if that's part of the problem.

By the way, for the fun of it, on the 2.6.33.3-l1-rt19 "pre-built" kernel, I also tried to do a "sudo depmod -a", "udevadm trigger" and "modinfo -d zram" and got nothing back, just a command prompt, no description returned, just like what happened with the DIY RT kernel, but there we were seeing "Ramzswap error" on boot-up, I don't see anything like that with the "pre-built" RT kernel on boot-up.

Also, past couple of power-downs, I'm not seeing the ACPI message anymore, not sure why it popped up in the first place.

Thanks,

David

[Rich]

Hi MTCAT

... I do notice that there's some Adobe Flash related stuff, and Opera related stuff in /opt/.xfiletool.lst ?, ...

That's a generic list of stuff to exclude from the backup. Leave it as is.