At my work we are trying to debug firmware code locally as if one could debug it like typical software. Right now this is done through dongles and ran on the firmware itself. We have looked into QEMU but our firmware has some proprietary device models such that, if we customized the QEMU device models, would cause licensing issues due to QEMU's GPL license.
When I have looked around for alternatives to QEMU, there were about three kinds of emulation software that had licenses free enough such that device model customization would not be an issue:
OpenStack
bhyve
box86
However, none of these seem to fulfill a use case similar to QEMU, OpenStack is more for cloud applications, box86 is more for games, and bhyve doesn't even have a download link. And much of the other alternatives I found either had the same licensing issues as QEMU, did not have an open source license, or did not deal in firmware simulation.
This leads me to ask: Is there a tool out there that makes it possible to wholly simulate the source code for firmware locally?
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 start some Linux development for my research. Writing few simple scheduling algorithms and test them. I have few questions:
1) How do you develop for the linux kernel? IDE? How do you import the kernel files and see how they are related or connected?
2) Once you write your code, how do you simulate/debug it? I mean one can't just build the kernel for 20 - 30 minutes, make a new image and change boot.ini each time. This is a lenghty process plus you can't simulate or debug just observe if it works or not.
3) Is there A guide for starting developing in Linux. I find the lack of documentation surprising
I am developing for ARM-based boards
Excuse my ignorance.
Thanks
How do you develop for Linux kernel?
There are many components in the Linux kernel. Typically, kernel is divided into core and driver parts.
Core includes scheduling, MMU, memory management, process management etc
Drivers includes file system, networking, peripheral device drivers, USB etc
IDE is not a must to develop kernel code. For kernel veterans, VIM/nano is also OK. The development environment is up to you. If you are new to the kernel code, you want to build the function relationship views, some tools can be helpful:
Source Insight (Commercial)
vim + ctags (http://vim.wikia.com/wiki/Single_tags_file_for_a_source_tree)
How to debug it?
There are many Linux favors/distributions. You can use Software emulator or Hardware boards to debug the kernel. Android is based on Linux and there are many mobile phones or development boards that support Android. iOS is also derived from Linux and it is its own debug method.
Where to find the kernel documents?
For kernel part, there are many readme articles in kernel source tree. e.g. http://lxr.free-electrons.com/source/Documentation/debugging-via-ohci1394.txt
printk is powerful enough for newbies.
For ARM part, there are many articles in infocenter.arm.com
Debugging Linux kernels using DS-5
http://infocenter.arm.com/help/topic/com.arm.doc.den0024a/ch18s03s03.html?resultof=%22%6b%65%72%6e%65%6c%22%20
Context
Debian 64 bit. kernel 3.18.x
Litterally struggling to understand how a network driver is initialized.
I mean how to choose which flag to set. I dig in the kernel for days now to train myself. The card setup is the only point I miss.
I take the intel 82574 as an example. I downloaded the card's datasheet, saw many information but not a clue on how to setup the hardware.
Question
Where to start to know what flags to set ? The datasheet didn't helped me (i am not very experienced but willing to learn).
Please give me a starting point, a tip or anything to help me understand what is going on in the already written open sourced driver.
How can a developer knows how to initialize his nic ? (yes reinventing the wheel the time to understand)
You'll need to read the source code of the kernel module that handles your specific NIC.
EDIT: Of course, to develop such a module, you'd usually just use a register map as specified in a data sheet or application node; often, manufacturers develop their linux drivers themselves, so the driver developers might even be the same people that developed the chipset (because it's really handy to have a platform to test against -- it's impossible to test hardware without having something like a driver, so you might as well write a proper driver).
Furthermore, devices often come with code examples -- no one is going to build a device based on an IC that he has not seen in action.
If you've got access to neither proper documentation nor source, you can only reverse engineer - and that's an incredibly large field.
Using your example with the Intel 82574 Network Adapter, Intel provides a zip file of the source code used to build the Linux driver. The driver is like all drivers in that it hooks into the OS API for Networking.
The Linux networking API is document on both the linux.org site and discussed on popular Linux sites like lwn.org. Below is the link to lwn's chapter on Network drivers using the networking API called NAPI.
https://static.lwn.net/images/pdf/LDD3/ch17.pdf
You'll notice in the Intel igb driver source code that the NAPI net_device data structure is one of the first things that is setup. It registers the driver with the OS. This way the OS knows which igb functions to call when loading/unloading the driver, or when needing to send/receive data.
The igb functions read/modify/write the necessary bits in the 82574's memory-mapped registers that control and monitor the device. The device registers are all documented in the 82574 datasheet available on Intel's site. And this is usually the case for almost any networking company like Broadcom/Chelsio/Mellanox/Marvell.
Hope that helps a little more.
This may be a foolish question but I've been searching around for some time and don't see a clear answer. I've seen several microcontrollers advertised as running Unix-like software (Linux, Ubuntu) for example, the BeagleBone Black and Arduino Yun. Can someone please explain to me the benefit of this? So far I've used a couple of microcontrollers like the Arduino Uno/Duo, Freescale FRDM and STM32 Discovery which either didn't have this feature or I was not aware of it. I'm starting to see it more and more on newer microcontrollers so I'd like to know what it brings to the table.
Full disclosure: I've had minimal exposure to UNIX and its variants so far so please talk slowly and use small words =)
Hope to hear from you,
Yusif Nurizade
You get complex drivers already included Linux for free (USB, internet protocols, storage media and file systems).
You can use lots of free software for the things not included in the kernel.
It is simpler to develop software on a full OS (easier to debug, look what is going on, change the configuration, etc etc).
The drawback is that the real-time capabilities are generally worse than for some small RTOS, and it needs more resources (a couple of megabytes memory).
In the heart of all Android and iphone is a Embedded Linux System. Without getting too deep
Linux + Java = Android
BSD Unix variant + C/C++/Object C = iOS
Now if you get deeper the above two statement can be argued for accuracy
All Android devices run on ARM based microprocessors. Beaglebone is one such open source hardware platform with can run Android as well as Embedded Linux distribution and even a Ubuntu.
Now (IMHO) Ubuntu is primarily for desktop and server application. Many of the popular computer server farms uses Ubuntu.
Now STM32 is a ARM based CORTEX-M micro control. Once again (IMHO) is mostly used for bare metal embedded applications. I have hard that FreeRTOS can be ported to TM4C123 ARM Cortex-M TM4C123.
Now the advantages of using Linux base micro controller architecture are
OS is free for the most part
Larger community of users
The industry is moving towards open source
Lot of free resources get up to speed
Disadvantage are
Learning curve is pretty steep
Expect to stumble and fall a few time
Below to two good resources to learn Beaglebone open source development
Beaglebone
Introduction to Beaglebone development by Derek Molloy of Dublin City University
HTH and good luck
I wanted to validate/test/benchmark set of features I have added to the ext4 kernel_tree/fs.
I came across Spruce Linux file system driver verification. Especially for filesystem.
The project is hosted #https://code.google.com/p/spruce/wiki/GettingStarted.
and this is for x86.
I work on arm target, and I have few questions before starting off.
Has anybody worked on Spruce earlier.
how to use Spruce project for ARM, Do we need to port for ARM?
Is cross compilation straight forward or any changes need to be done.
I have gone through this paper: http://syrcose.ispras.ru/2012/files/submissions/25_syrcose2012_submission_21.pdf
there is no information on ARM and its support.
Please someone explain/help who has any work experience/knowledge on Spruce project.
Spruce was intended to work as follows. It provides a set of tests that make the kernel module for a given file system execute as many paths in the code as possible. It allows to use some external analyzers (such as the tools from KEDR framework) to detect different kinds of errors: memory leaks, etc.
All that was primarily intended for x86.
While it might be possible to port the tests themselves to ARM, one will need to choose the analyzers that work on that platform too. KEDR tools are currently for x86 only but one may try Kmemleak, Fault injection facilities and other tools on ARM instead.
Spruce seems to be a work in progress still. I see, you opened a ticket concerning ARM support in their issue tracker, I think, it is the right thing to do.
I would also suggest to take a look at Phoronix Test Suite. It is currently widely used for testing and benchmarking, including the analysis of file system kernel modules. See this article for example. It seems to work on ARM although I haven't tried it there myself.
The best tool for testing/validating a file system is xfstests. I have written tools to make it easy to validate xfstests for ext4. See: http://thunk.org/gce-xfstests for more details.
There is also an alpha-test level support for using this on ARM directly: http://thread.gmane.org/gmane.comp.file-systems.ext4/53649/focus=53659
This has been used successfully to test ext4 on an Android device, although to be honest, most of the time what I do is to bludgeon an Android kernel until it will build on x86, and then use kvm-xfstests gce-xfstests, since it's much more convenient. In particular with gce-xfstests, I can just do a "fire and forget", and then when the test completes I get a test report in my e-mail. Where as with the Android arm xfstests tarball, the automation isn't done yet, so you have to manually set up an external USB-attached USB device, hook it up via some kind of USB C hub, or if you are going to use an OTG usb adapter, you need to make sure the Android device can receive power while it is also driving the OTG usb port --- and you have to manually set up the chroot. Unless the BSP kernel has been badly abused so you can't figure out how to make it build on x86 (getting the MSM kernel to work on x86 wasn't easy) testing on gce-xfstests may be much simpler at the end of the day.