Can anybody tell me what's the difference in supporting I2C between kernels until and after 3.10 version?
Looks like after 3.10 something changed but I can't realize what exactly. I'm working on Intel Core-i5 2500k CPU with integrated video and am using ddccontrol tool to change brightness on my monitor. But if on kernel 3.2.32 I can do that, since 3.10.5 I2C support seems to be broken.
I don't know what exactly changed, but there are outputs from old and new kernels (i2cdetect -l):
3.2.32: http://pastebin.com/SqDPcwS9
3.10.5: http://pastebin.com/YCTmX90m
If on 3.2.32 I was able to use i2c-4 device to control my monitor, then on 3.10.5 list of i2c devices is shorter, and I don't see any GPIO buses (or what does it mean). On 3.10.5 system detects only monitor on i2c-1 but says that there is no support of DDC/CI on that device (http://pastebin.com/vZ4bALmt). For 3.2.32 everything is OK: http://pastebin.com/QL0fAZVC
Maybe I don't know something, e.g. some new config option have been added/changed in kernel.
Seems I'm not alone in my trouble - there are a lot of questions about I2C and ddccontrol around the web, but there are still no answer.
Need your help, really...
Thanks!
---
UPD: on kernel 3.7 I've watched the same behavior as on 3.10, so, the breakage isn't at 3.10 but a bit earlier
I'm not sure, but I think this has been fixed in commit 59b016fe8fe83920e8717163289e61ab8e327b90 the 17.10.2013
Can you try a more recent kernel (3.12) ?
Related
I noted that the actual brightness of my laptop monitor is different on the same value(s) for backlight from the same range of available values when running Linux with kernel 5.4 vs. 3.13 (i915 driver). What might have changed to result in that? I like the 3.13 one better.
TL;DR
I noted backlight works differently on my laptop now on 5.4 kernel than on 3.13, range of values to write to /sys/class/backlight/intel_backlight/brightness is the same, but perceived brightness at 1 is much lower on 3.13 whereas max seems same.
I've found out most probably backlight on my laptop is controlled by i915 driver and source code in https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/i915 (it is a mirror per Why does the Linux kernel repository have only one branch?, but on kernel.org I do not know how to open a tree of code to provide a web link to the driver).
How to find code that process input to /sys/class/backlight/intel_backlight/brightness? Hints on what to do next are also welcomed.
I'm currently struggling to determine how I can get an emulated environment via QEMU to correctly display output on the command line. I have an environment that displays perfectly well using the virt reference board, a cortex-a9CPU, and the 4.1 Linux kernel cross-compiled for ARM. However, if I swap out the 4.1 kernel for 2.6 or 3.1, suddenly I can no longer see console output.
While solving this issue is my main goal, I feel like I lack a critical understanding of how Linux and the hardware initially integrate before userspace configurations via boot scripts and whatnot have a chance to execute. I am aware of the device tree, and have a loose understanding of how it works. But the issue I ran into where a different kernel version broke console availability entirely confounds me. Can someone explain how Linux initially maps console output to a hardware device on the ARM architecture?
Thank you!
The answer depends quite a bit on which kernel version, what config options are set, what hardware, and also possibly on kernel command line arguments.
For modern kernels, the answer is that it looks in the device tree blob it is passed for descriptions of devices, some of which will be serial ports, and it initializes those. The kernel config or command line will specify which of those is to be used for the console. For earlier kernels, especially if you go all the way back to 2.6, use of device tree was less universal, and for some hardware the boot loader simply said "this is a versatile express board" (for instance) and the kernel had compiled-in data structures to tell it where the devices were for each board that it supported. As the transition to device tree progressed, boards were converted one by one, and sometimes a few devices at a time, so what exactly the situation was for any specific kernel version depends on which board you're using.
The other thing that I rather suspect you're running into is that if the kernel crashes early in bootup (ie before it finds the serial port at all) then it will never output anything. So if the kernel is just too early to support the "virt" board properly at all, or if your kernel config is missing something important, then the chances are good that it crashes in early boot without being able to print you a useful message. (Sometimes "earlycon" or "earlyprintk" kernel arguments can assist here, but not always.)
I'm having trouble with an industrial Linux computer I'm working with to achieve communication over an RS485 bus with multiple connected devices. What I've encountered is that the IO pins used by the RS485 USART driver are set to different levels at startup instead of going to the RS485 idle/tri-state. As a result, the other devices on the bus are blocked for more than 30 seconds while the device boots up, triggering all sorts of external problems. The course of events can be viewed in the attached image, where I've measured the output voltages with an oscilloscope during startup.
My guess is that the actual driver is not started until the voltage levels reach their tri-state levels (e.g. ~2.2V for this device). After that everything works as expected.
I've tried to find any config-files to set the default IO level of the pins at boot (thinking this may be set by the bootloader) to no avail.
Also, I've tried to apply a startup-script to run "early enough" to set DATA- high, but the device in question does not provide any interface to control these pins as regular GPIOs as far as I can tell.
Any help, tips or insights would be much appreciated!
EDIT: I am not an experienced Linux developer, so please highlight if I've left out any important details.
Some specs:
ARM920T rev 0 (v41) CPU
Proprietary distribution of Linux 2.6
Uses Busybox
Atmel USART drivers
Extract from boot log:
Linux version 2.6.28.10 (root#) (gcc version 4.1.2) #94 PREEMPT Tue Oct 29 10:22:19 CET 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
/...
.../
RS485 mode for port /dev/ttyS3 enabled
/...
... (I'm guessing the ~30 secs elapse here)
.../
atmel_usart.3: ttyS3 at MMIO 0xfffcc000 (irq = 9) is a ATMEL_SERIAL
atmel_serial.3: Putting the RS485 RTS pin down
/...
...
.../
Full boot log: https://drive.google.com/file/d/0B2XYl1mNCa8jNUZ5V0Nic1hkU0U/view
Similar issue:
Possibly a similar issue is discussed here: UART initialisation: Prevent UART to pull RTS high
But I'm not sure how to proceed with the suggested solution.
This is little more than wild speculation, but it might be worth adding a start-up script that echoes a NULL character to the device (e.g. /dev/ttyS1 or whatever) as early as possible during start-up. This might be enough to kick the driver into initialising the hardware.
You could also try to locate the driver in the Linux source to look at how it starts up.
Probably you have access to the source code, so you can investigate who and when mess with the that GPIO. Just grep the kernel source for the atmel gpio controller port addresses to figure out what happen. If you are lucky may be there will be kernel command line option that you can pass from the bootloader to set the line to what you need in advance.
this answer may work if you can find required things mentioned below
of your board!
Once I also had a same issue on PWM. There I found that my bootloader was responsible for the same, I changed in bootloader configuration and it started working fine.
Check your BSP provided by board vendor or third party (If you have the source), If your bootloader is U-boot you can find it inside U-boot-(source)/include/configs/(your-board).h there you can find configuration for RS484. As per your datasheet for the board you can check for other things which are muxed on the same pin and disable those if not required for boot time and enable RS485.
enabling/disabling can be done by changing the values 0, 1 or 2 as per your configuration and also you can simply disable anything just by commenting // out the line.
I am aware of windows kernel but new to linux kernel. I just need to know how its done in linux, i.e. the program development.
You can check there (free-electrons.com), it's a good informations source for kernel developement. (specialized in embedded linux, but most of the docs are available for standard development)
You have also the classical Linux Devices Drivers, which is very complete and detailled.
And last but not least, the Linux kernel documentation.
Linux does not have a stable kernel API. This is by design, so you should generally avoid writing kernel code if you can; it is unlikely to remain source-compatible indefinitely, and will definitely NOT be binary-compatible, even between minor releases.
This is less-or-more true for vendor kernels; Redhat etc DO maintain source & binary kernel compatibility between major revisions.
More work is gradually being done in the kernel to reduce the amount of kernel-code required to carry out various tasks, such as driver development (for example, USB drivers can typically be done in userspace with libusb), filesystem development (FUSE) and network filtering (NFQUEUE). However, there are still some cases where you need to; in particular, block devices still need to be in the kernel to be able to be usefully used for boot devices and swap.
Is there any way to programmatically disable Turbo Boost on a Core i7 mac running Mac OS X ? I need to be able to do this for benchmarking purposes during code optimisation etc. Failing that, any kind of utility which can disable/enable Turbo Boost, even if it requires a reboot, would be useful.
There is a related question (not Mac-specific) on SO: How to turn off Turbo Boost temporarily? but even for PCs it seems that there may be no way to do this programatically/on-the-fly ?
I wrote kernel extension that let's you disable TB, have fun:
https://github.com/nanoant/DisableTurboBoost.kext
If you want to disable TB on Linux here another recipe: http://luisjdominguezp.tumblr.com/post/19610447111/disabling-turbo-boost-in-linux
I've just coded an app that allows to load / unload the kernel extension mentioned before, helping to track the system behaviour displaying CPU Temp & current fan speed.
You can check it out here https://github.com/rugarciap/Turbo-Boost-Switcher
Here is an screenshot of how it looks like http://i.stack.imgur.com/tsKaG.png
You can't. Certain stuff needs to be configured from the BIOS, such as TurboBoost or Vt.
In particular, this is done with the IA32_FEATURE_CONTROL MSR. On a PC, at boot time the MSR is unlocked and the BIOS sets the correct bits to enable or disable features. Once configuration is complete, the BIOS locks the MSR for the changes to take effect and prevent future modification.
I don't know if it's possible to unlock the MSR again before the PC is brought into protected mode, and I don't know how this works on a MacBook where EFI is used instead of BIOS. You'll probably be able to pull it off with an EFI extension of sorts.
CPUID.com's Tmonitor utility can disable/enable Turbo Boost on-the-fly from within Windows, not at boot! There must be a way to do the same thing from within OSX.
Finally there seems to be a good solution for this problem which I have tested with Mac OS X Lion on a Core i7 MacBook Pro today and it appears to work well. Adam Strzelecki, a researcher in parallel computing at Jagiellonian University in Krakow, Poland has written DisableTurboBoost.kext - this is a small kext which can be loaded and unloaded at will (via the command line) to disable/enable TurbBoost.