Tiny Core Extensions > TCE Talk
[Solved] TC3.8_4 Real Time Upgrade
MTCAT:
Hi Rich,
I attached the output of lsmod for the "original" non RT kernel here, and dmesg as well.
Thanks,
David
MTCAT:
Hi Rich,
Here's the output of lsmod and dmesg for the "home-made" or "built from scratch" RT kernel (this is the RT kernel where we had to run "sudo udevadm trigger" to get the OS to see the ethernet port).
Both the "original" non-RT kernel, and the "home-made" RT kernel are able to see an "ACPI" thermal zone0 which always reports 66 C.
Both the "original" non-RT kernel, and the "home-made" RT kernel have slightly different ACPI behaviour (see lines 288 to 292 in their respective dmesg files) as compared to the "pre-built" RT kernel.
For some reason, the "pre-built" RT kernel doesn't show this ACPI behaviour, the "thermal zone" entries are missing from it's dmesg file (see latest_dmesg.txt), something must be different with how ACPI is configured perhaps ?
In any case, I'm a bit suspicious of the 66 C reading when it is available anyway, I don't see any temperature readings at all in the DX3 BIOS, so....., I've queried WinSystems to see if this board (PPM-C412) has any onboard temperature sensors at all, hopefully they'll respond in the next few days.
I suppose if it doesn't have any temperature sensors, I could either add my own somehow ?, or simply comment out the "sensors" line in the acquisition code and feed the program dummy temperature readings, which would be a shame, as that's useful information to know, but would keep the program happy at least.
Thanks,
David
Rich:
Hi MTCAT
The working kernels don't appear to be loading any modules related to temperature monitoring. It's possible some modules
built into the kernel are being used, but they wouldn't show up using lsmod.
You can see if any of these boot codes make any difference:
--- Code: ---apm=on
apm=smp
acpi_pm_good
--- End code ---
A list of boot codes valid for a 2.6.33 kernel can be found here if you're interested:
http://redsymbol.net/linux-kernel-boot-parameters/2.6.33/
Just a thought, but if temperature really is important, a better option would be to connect a sensor to one of your
A/D channels and get it that way.
MTCAT:
Hi Rich,
Thanks for the ideas, I tried those boot codes but nothing worked, except sometimes the boot "dead-time" (the dead time when the DX3 sits there seemingly doing nothing after loading the 24DSI driver) seemed to be eliminated, or much reduced.
But, I'm not sure if the DX3 even has a built in temperature sensor, so until I hear otherwise from WinSystems, I may as well just return dummy values in Peter's subroutine for temperature, I did find out that lm_sensors won't work with the acpitz "digital" sensor, see the "Hardware Support" part, laptop discussion, in here
https://github.com/lm-sensors/lm-sensors
For now, I think I'll move on to getting chrony to save the necessary log files (position, date, time, etc) and hopefully get the acquisition code up and running at least.
Inside the attached program, lines 61 to 90, I think I could comment out all the lines except for lines 61, 90, and then change lines 87 and 88 to something like,
*cpu_temp=50.0;
*board_temp=50.0;
I think that would work ?, to simply return dummy values of 50.0 C from subroutine get_temperatures ?
Thanks,
David
MTCAT:
Hi Rich,
Sorry, forgot line 68 would need to remain uncommented as well, so all lines commented except for 61,90,68 and then change lines 87, 88 to dummy values of 50.0 C.
Thanks,
David
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version