and I want to know if my chipset is capable off doing those things
My chipset is a intel centrino advanced 6200-n on a sony vayo laptop running on windows 7.
Now, I know that windows is only capable off listening, so I boot backtrack 4
from a usb stick.
I also want to know if a live distribution can work flawlessly with the wificard even if it does not support formentioned things, because I try'd to use wget to download something
and it says it ca not resolve the address?
thanks, Richard
Intel centrino advanced 6200-n does support both monitor mode and frame injection with iwlwifi driver. There are some intricacies involved on driver side though so it is best to use very recent kernel to make it work reliably. The patches which make this work well are expected to be part of Linux kernel version 3.5, until it's released you can build kernel yourself from iwlwifi.git tree:
http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi.git
Instructions on building kernel from a git tree:
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
It should also work with older kernels.
As for the fact that you couldn't wget something - have you connected to wireless network at all? Standard client mode in iwlwifi works very well even with old kernels.
Related
I may have a couple assumptions of Linux incorrect about the Linux system, and for that I apologize.
I have been educating myself on the Android and Linux systems for a while now and I started looking into installing a custom boot loader and Linux system onto an older Samsung tablet. Immediately upon looking into the feasibility of this, most of the answers I could find were that it wasn't possible because you would need the drivers that are being used by the android kernel to communicate with the OEM hardware in whatever Linux kernel you are installing.
I have one of these tablets rooted and I believe I may have found the drivers I need (not sure on that yet), and so I guess my question is, is it possible to take the drivers and put them into a Linux kernel within a distribution install image and install Linux on the device (using also a custom boot loader)?
I presume because someone hasn't done this before there is a pretty good reason why, but I am basically looking to be able to use Linux on my old tablet without the resources being taken from Android, and personally in my opinion, if I don't need Android and can install Linux straight on to the machine, then why keep it?
In the long run I am looking into LFS to create a custom distribution that can be installed on these tablets, but the most important question to me right now is if I do create this distribution can I get the drivers that the hardware needs (and even then will my kernel be able to use them?).
I also understand that some of these drivers may be proprietary drivers provided by the manufacturer, but I am not looking to profit off of this but instead research the feasibility of a better personal on-the-go computing setup.
I may be terribly wrong on how I may have described some things, so here are some of my assumptions:
The .ko files in the Android /lib/modules/ directory are the static kernel drivers I am looking for for that device.
The drivers aren't written for specifically the Android system, but for all Linux variants and would be compatible with another distribution.
If the drivers were written for the Android system, then one would be able to edit or modify those drivers to work with a different distribution.
One could "put the drivers into an installation image", or if not, then one would have to compile the kernel from source with those static drivers.
TL:DR, If this all just amounts to rambling, here are my specific questions:
Is it possible to copy the static kernel drivers of a rooted Android device to something like the SDcard?
Is it then possible to "put" or "compile" those same static drivers into a Linux distribution before installing it onto said tablet using something like Odin, or the like?
I want to write a driver for sensor which can tell me if my yoga 2 pro is in tablet mode or not.
I read some about writting modules but as far as I know, I need to know address in memory which belongs to this device (hope it's correct), and here is my question.
How can I find information about this address?
Or what should I do to find this address?
Both in Windows and in Android you absolutely don't need to write a driver for this purpose. To identify Tablet/Laptop mode, you need just one sensor - accelerometer. In Windows 8.1 + this functionality is built-in, but in case you wish to build your own application you can use an example from here: https://code.msdn.microsoft.com/windowsapps/Accelerometer-Sensor-Sample-22982671
In Android, you have a Java API to all sensors:
https://developer.android.com/guide/topics/sensors/sensors_overview.html
However if you have a custom Linux installed on your Yoga, there indeed may arise a need to add a driver. As of now, the most useful solution are IIO drivers that are part of Kernel:
http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf
If there aren't already there, you'll have to rebuild a Kernel and include those drivers. If you don't know how to find a device address, you have to learn for a while about Linux Kernel in general. Anyway, some tips:
Sensors are normally defined via USB/HID interface
If you still have your Windows along with Linux, you may go to
Devices Manager and there you can easily reach Sensors and see what
address is used by a driver.
We are developing a multi-core processor with RISCV architecture.
We had already ported Linux for single-core RISCV processor and it is working on our own FPGA based board with busybox rootfs.
I want to port Linux for multi-core RISCV processor now.
My doubts are:
Whether the gnu-riscv-gcc toolchain available now supports multi-core?
Whether spike available now supports multi-core?
Should I make any change to the bbl bootloader (Berkely bootloader) to support multi-core?
What are the changes I should make for my single-core Linux kernel to support multi-core?
The current RISC-V ecosystem already supports SMP Linux.
No changes to the compiler are required for multicore.
Spike can simulate multicore when using the '-p' flag.
BBL supports multicore.
Before building linux, configure it to support SMP.
Any hiccups, are probably due to the toolchain out of sync with the newest privileged spec changes. Last Fall, users successfully built and ran multicore Linux on RISC-V.
This is all expected to work out of the box. My standard testing flow for Linux and QEMU pull requests is to boot a Fedora root filesystem on QEMU via Linux+BBL. Instructions can be found on the QEMU Wiki Article about RISC-V. This will boot in our "virt" board, which uses VirtIO based devices. These devices have standard upstream Linux drivers that are very well supported, so there isn't really any platform-level work to be done.
In addition to the standard VirtIO-based devices, SiFive has devices that are part of the Freedom SOC platform. If you platform differs significantly from SiFive's Freedom platform then you'll need some additional drivers in both Linux and BBL.
We maintain an out-of-tree version of the drivers we haven't cleaned up for upstream yet in freedom-u-sdk, which should give you a rough idea of how much work it is. Running make qemu in that repository will boot Linux on QEMU via BBL, and running make will show you how to flash an SD card image for the HiFive Unleashed board.
I am trying to setup a Tegra 3 (Toradex Apalis T30) based system that will have an OpenGL ES based user interface on a touch screen. Unfortunately the standard Linux4Tegra kernel is seriously outdated and the provided graphics driver requires X11 integration. I have found though that I can build the Vanilla Linux kernel and get it running just fine on my board (tested 3.18). I have also found that a DRM Tegra driver is included in the kernel these days and I enabled it in menuconfig and built the kernel using it. I have also managed to get many distros working with the kernel (though I haven't really tried getting X working on any one).
My problem is that beyond this point, I am stuck. I cannot figure out what to do next in order to get GLES rendering up and running with the DRM driver. I have looked around a bit and have seen that Mesa might support GLES via DRM but I am not sure if this will allow me to do so without X? Also, how on earth to I get Mesa configured and compiled for the Tegra DRM driver?
Also, how does one go about configuring the output display using this DRM driver? My target screen is a 24bit parallel RGB display but I have not got that hooked up yet and would like to test with HDMI first. I have literally no idea how one should go about configuring the output display. The only information that I can find that might help involves X and xorg.conf which I will hopefully not be using. My device does output the console correctly on the HDMI display, how does it know to do that? Might this process somehow involve the device tree?
PS. I guess this question is a bit stupid but I am very new to embedded Linux and have just figured out how to build the vanilla kernel etc. and have really no idea of how the Linux display system works beyond just configuring X. Finding information regarding this is also proving hard.
EDIT:
I have gotten XFCE sort of running on HDMI (login does not work and the login windows is very tiny) on Fedora using the OpenTegra driver which in term uses the DRM driver if I am not mistaken so hopefully that is good news?
Nvidia-setting can usually clear things up if you've gotten this far. Typically the video will work if the kernel has been given the correct vesa mode to show the system bootup messages. These are somewhat cryptic but they simple turn into an argument you append to the kernel boot parameters "vga=###".
We are porting a solution to ARM that was originally designed to run on x86/x64 Debian based systems.
So far so good however along with this solution we ship out a printer that is compatible and comes with drivers for Linux (x86 and x64), unfortunately the manufacturer does not have ARM drivers for it, nor is capable of compiling some from source code (don't know why).
I've installed the printer with CUPS and used the x86 binary. But of course, whenever I send a task to the printer, the ARM system cannot use the binary and naturally CUPS reports:
/usr/lib/cups/filter/rastertotg2460 failed
I would like to know how I can run x86 binaries on ARM v6 based systems?
The ARM operating system is Raspbian running on a Raspberry Pi B+ board and the binaries (if you want to take a look) are here.
EDIT:
I was also made aware of this proprietary solution that claims to make it possible running x86 binaries on ARM systems, but all demonstrations are for ARM v7 systems, not sure if it will work on Raspbian with a Raspberry Pi B+ board.
I think this is going to require some serious work, but I had it the wrong way around initially.
Since you want to drive the printer, you're going to have to do the x86 emulation "inside" the CUPS system. It's not enough with a stand-alone x86 emulator, since those aim to give you a full x86 system with peripheral hardware and stuff. You don't need that, you just need to drive the printer.
I can imagine using some kind of x86 emulation library inside a CUPS "virtual" driver, which in turn loads the x86 binary you have and feeds it into the emulator. It would then need to expose the expected CUPS environment to the x86 code inside the emulator.
Something like Soft86 might be a good starting-point.