I have ARM-based device with linux on-board. Its very difficult to flash custom kernel for some reasons (uBoot cant load kernel via tftp or something else)
I need to test my custom kernel.
So, idea is - replace kernel in memory. How do you think, is it possible?
Tell me any suggestions please.
Take a look at this link
It's for a project called Ksplice that allows one to patch a running kernel.
At one point this code was open, but Oracle bought it... So they may have closed it up and made it cost money. If that's the case, look around and see if you can find the formerly open code in the wild...
Related
I am trying to build minimal kernel under 1 Mb with Buildroot. It is intended for small board with qspi memory and basic functionality, ethernet, usb, spi, and some GPIO's. Basic terminal access via ssh and UART.
My first thoughts are if it is even possible to modify kernel .config via linux-menuconfig to reach this size.
Also if it is possible to identify the redundant parts without deep knowledge about kernel architecture and exclude them from compilation.
If someone can direct me to good direction how to solve this problem or even specify some tools and ways how to do it would be very helpful.
Thank you!
If you have working build root for your board, than, it's better to continue to work with it. Technic for disabling kernel options should be the same. In the article he reached ~0,7MB uImage with lost a lot of functionality (p40). He started with minimal (bare) config (p27) and add blocks of configs. So instead of identify the redundant parts you can build smallest possible uImage you can boot. Than add to it more options: ext2, serial and so on. Actually this work require a lot of testing. And you probably brake dependencies.
Kernel configs (working and new one) could be compared using diff -Naur, so you can see what changed.
Offtopic:
Looks like yocto officially supported by altera. here are instructions how to build altera-image-minimal. If you fine with it size, than use it and don't spend time on minimizing uImage. If you need extra packages installed into it, than you can ease extend it.
And here are instructions about building Angstrom (yocto based distribution). You can create you custom image based on console-image-minimal.
I use Angstrom in production. Must say, it was really hard to use it first time.
Whether or not you build the kernel with buildroot is not really relevant. The important thing is to configure it so it fits in 1MB. When you build the kernel from buildroot, you can do that with make linux-menuconfig, as you mention.
That said, getting a kernel under 1MB will be quite hard. Biff once did this for an x86-based platform, bifferboard. But that was without networking or USB.
You can refer to the kernel size tuning guide, which has links to some patches to reduce the size. But it's not been updated in a couple of years.
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.
So, I know Linux kernel is quite "heavy" when considering lower scale embedded systems, but currently but we're a 2 man team trying to see how to create our own embedded system.
I'm the one in charge of all software (the other guy is a HW guy), and thus I would like to re-use existing libraries and frameworks as much as possible, and I would like to bounce off some ideas with gurus around here.
I am fairly comfortable in Linux, but the booting and initialization process is new to me, and I need to dive in to that soon enough. Any book recommendations are welcome as well!
I haven't designed any embedded systems before.. Only own some ARM dev boards (beagleboard and raspberry pi).
Current I have prototype of the software running on beagleboard already, and now we're thinking how to minimize the cost, and to create something our own..
It's a system connected to the internet, and I need to run a tiny web server with some scripting support. Performance wise I don't think it needs to be too powerful.
I would like to minimize all bootloader etc work, since I'm a one man SW team, and just concentrate on the application itself.
Of course I understand that I need to configure our kernel for this, but this is indeed why I thought selecting some SoC would be good, since they usually have some linux and bootloaders ready..
First I thought that Cirrus EP9301 would be perfect, since it seems to be a good package, and not very expensive.. But it seems that it's already in end-of-life, and also support for this is very bad (people on the cirrus forums constantly complain about it).
Are there some good choices for this kind of project, which would enable us "easily" to get linux kernel up and running, with still maintaining some kind of decent BOM (hopefully 20USD or so) ?
Your hardware guy should already know this, but go with an existing reference design. Take the raspberry pi, the beagleboard/bone, open-rd, or any number of other existing systems and clone the part you need. As a result the linux porting will be a matter of removing what you are not using from the reference design instead of adding new stuff and hoping it works. If you go with flat pack parts you can do the work in your garage, if you go with bgas you need the equipment for that or pay someone to do it. (can you tell yet that I hate bgas?).
Is linux a requirement, if not that opens the door to a lot more devices using freertos or chibios or a number of other solutions. the stm32f4 discovery board for example is $20, uses what can barely be called a microcontroller for all the features it has (cortex-m4). Supposedly possible to run uclinux on a cortex-m, but definitely possible to run any number of rtoses and have an ip stack, etc. stellaris (ti.com) has a number of eval boards, one/some with ethernet already (use as a reference design). You can also take the wiznet approach (or a spi ethernet) and use any microcontroller (puts you into the avr/msp430 level and price range). Bang for buck the cortex-m's are good, arm based so comfortable to work with, etc.
Using linux if you are already not an experienced at porting to an embedded platform, and dont want to learn that on this go around, I would definitely go with a clone of an existing design, leverage as much as you can from a project with folks that are experienced at porting linux to a platform. If need be take an existing board (beagle/raspi/openrd) and go through the motions of porting to the platform with the cheat sheet of having access to an existing port, see if you cant get uboot ported and linux booting, etc. (dont really need uboot at all, that is possibly an unnecessary complication, just get dram up and pass the atags, etc to linux and just branch to it, pretty easy to launch linux from bare metal).
You could probably do worse than taking the Broadcom BCM2835 - used on the Raspberry Pi - as your starting point - especially if you want to avoid kernel and boot-loader work and a source of reference schematics. If this proves too expensive, check out other devices in the Broadcom range.
A few bits of advice
You probably want some flash rather than a MMC card interface for production use. eMMC is an option. NAND flash is a nightmare due to rapid component obsolescence and the need to get own and dirty with the MTD drivers.
USB Ethernet will be easier to integrate than a controller hanging off a general purpose bus, but won't perform as well. SmSC seems to be popular source for either
You could also have a look at the work that Olimex is doing with their linux boards. Perhaps even order a som and then combine it with other external components.
I've spent a lot of time developing an operating system and working on my low level boot loader. But now I want to take some time off my operating system while not leaving the low-level environment and doing something involving security.
So I chose to build my own standard password utility following the pre-boot authentication scheme. Since I want the software to be at least a little portable I want it to use as little external support as is possible. I figured that I'd be best if I somehow managed to 'hook' into the bios somewhere between the self checks and the int 19 bootstrap from within a running real mode OS.
However finding information on how to modify the bios code proved to be impossible. I've found nothing on how to achieve the before mentioned. I have only found pages describing how to flash your bios.
Does anyone know how I can read/write bios code? Or can someone provide links to pages that describe this?
I know that it's not only possible to brick my device but it is also likely, I'm aware of the risk and willing to take it.
Pinczakko's articles on BIOS reverse engineering are a great place to start looking at this. There was also a book published by the same author but it is now out of print.
I'm not sure if this approach is the best approach towards a secure boot, but the articles on this site are very detailed and should point you towards a method for modifying your BIOS firmware.
I'm not really sure what you are trying to achieve, but:
The BIOS is completely hardware specific - each manufacturer will have their own mechanism for updating / flashing BIOS and so trying to come up with a portable mechanism for updating a BIOS is destined for failure. For example when using Bochs you "update" the BIOS by specifying a different BIOS ROM image.
If you want to modifty / write your own BIOS then its going to be completely specific to that hardware. Your best bet would be to start with something like Bochs as its open source - as you can take a look at the source code for the BIOS (and easily test / debug it) you stand a reasonable chance of understanding the BIOS code and modifying it into something that works, however I suspect this isn't what you are trying to do.
Why not just perform this authentication as your OS boots? If you want to protect the data then you should encrypt it and require that the user supply log in / supply the decryption key on startup.
If you were thinking of working with "legacy" PC BIOS, I would dissuade you from trying for many of the reasons Justin mentioned: 1) legacy BIOS is PC vendor-specific; 2) it is closed source and proprietary; 3) there are no industry standards defining legacy BIOS interfaces for extending the system as you are trying to do.
On the other hand, if you have access to a UEFI-based BIOS PC, you may be able to write your own PEI/DXE driver(s) to implement such a feature. This will at least point you in the right direction:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome
Intel Press book on the topic: Beyond BIOS
Regarding the practicality of read/writing the BIOS, you'll need to identify the SPI part containg the BIOS and get a ROM burner. The SPI part may or may not be socketed; if it is not socketed, you'll need a soldering iron and be able to create a socket/header for the part. You obviously do not want to embark on this project with your primary computer system. Perhaps you could find an older system or a reference board.
A linux machine freezes few hours after booting and running software (including custom drivers). I'm looking a method to debug such problem. Recently, there has been significant progress in Linux Kernel debugging techniques, hasn't it?
I kindly ask to share some experience on the topic.
If you can reproduce the problem inside a VM, there is indeed a fairly new (AFAIK) technique which might be useful: debugging the virtual machine from the host machine it runs on.
See for example this:
Debugging Linux Kernel in VMWare with Windows host
VMware Workstation 7 also enables a powerful technique that lets you record system execution deterministically and then replay it as desired, even backwards. So as soon as the system crashes you can go backwards and see what was happening then (and even try changing something and see if it still crashes). IIRC I read somewhere you can't do this and debug the kernel using VMware/gdb at the same time.
Obviously, you need a VMM for this. I don't know what VMM's other than VMware's VMM family support this, and I don't know if any free VMware versions support this. Likely not; one can't really expect a commercial company to give away everything for free. The trial version is 30 days.
If your custom drivers are for hardware inside the machine, then I suppose this probably won't work.
SystemTap seems to be to Linux what Dtrace is to Solaris .. however I find it rather hostile to use. Still, you may want to give it a try. NB: compile the kernel with debug info and spend some time with the kernel instrumentation hooks.
This is why so many are still using printk() after empirically narrowing a bug down to a specific module.
I'm not recommending it, just pointing out that it exists. I may not be smart enough to appreciate some underlying beauty .. I just write drivers for odd devices.
There are many and varied techniques depending on the sort of problems you want to debug. In your case the first question is "is the system really frozen?". You can enable the magic sysrq key and examine the system state at freeze and go from there.
Probably the most directly powerful method is to enable the kernel debugger and connect to it via a serial cable.
One option is to use Kprobes. A quick search on google will show you all the information you need. It isn't particularly hard to use. Kprobes was created by IBM I believe as a solution for kernel debugging. It is essentially a elaborate form of printk() however it allows you to handle any "breakpoints" you insert using handlers. It may be what you are looking for. All you need to do is write and 'insmod' a module into the kernel which will handle any "breakpoints" hit that you specify in the module.
Hope that can be a useful option...
How I debug this kind of bug, was to run my OS inside the VirtualBox, and compile the kernel with kgdb builtin. Then I setup a serial console on the VirtualBox so that I can gdb to the kernel inside the VirtualBox's OS via the serial console. Anytime the OS hang, just like magic sysrq key, I can enter ctrl-c on the gdb to stop and understand the kernel at that point in time.
Normally kernel stack tracing is just too difficult to pinpoint the culprit process, so the best way I think is still generic "top" command, just looking at the application logs to see what are the cause of hanging - this will need a reboot to see the log of course.