Right now, I'm compiling with printk's, copy the resulting kernel to a USB stick, mounting the USB stick on the device, mounting the partition that contains the kernel, copying the new kernel from the USB stick to the partition, rebooting, then inspecting the trace by capturing the dmesg output to a file.
On workstation:
make my-kernel
cp new_kernel /path/to/usb/stick
On embedded device:
mount /dev/sda1/ /mnt
mount kernelpartition /tmp/kernel
cp /mnt/new_kernel /tmp/kernel
sync
umount /tmp/kernel
umount /dev/sda1
reboot
dmesg > mytrace
less mytrace
Is it supposed to this painful to develop? I don't understand how any meaningful amount of non-trivial kernel code is ever developed.
The best workflow is going to depend on the capabilities of the device you are working with. Often they will have a bootloader with options to boot from a network or serial port.
I'm doing some embedded development also, and here's what I came up with. The device I am working with has some built in flash which by default it boots from, but also has a USB port and an SD Card slot. It has a fairly primitive bootloader.
On the USB port I have connected a wifi dongle. I make sure that I compile the kernels with the needed modules to get the USB dongle up and running.
I have built a minimal kernel and root filesystem which I have flashed onto the device. This kernel has the option CONFIG_KEXEC enabled. The root filesystem has kexec tools. I build the system using buildroot.
When this system starts, it attempts to mount the SDCARD and checks to see if it can find a kernel in the root directory. If it can, then it uses kexec to boot this second kernel. This is done using a custom init script that I have written.
If you don't have an SD Card slot on your device, you could probably do something similar with a USB memory stick.
With this setup, I can just use sftp to transfer a new kernel image onto the sdcard, and kexec to boot it. It saves me the hassle of reflashing the device each time I change the kernel.
Related
I have an embedded linux device running a USB gadget kernel module to make the mmc available to the host PC(such as Windows or Linux).
When I update the file in mmc, it won't sync with host PC unless I rmmod and insmod again. Is there any better way to update new files? And how can I detect a file is modified by host PC? I'm using C programming on my linux device.
Thanks.
(1) There really isn't a better way to update new files. You need to take turns and only access the mmc from Linux or Windows, one at a time.
(2) You can't easily do that.
When you say "When I update the file in mmc", I assume that you have the mmc mounted in the linux device, and are updating files from linux at the same time that Windows has mounted the device. I don't think this is advisable. The host (Windows) may cache file and/or directory information from the mmc, and if the embedded Linux changes that information unexpectedly, it may produce errors from the Windows FS, and could corrupt the mmc.
If you want to share files between the embedded Linux and host Windows, and be able to modify them from either OS without taking turns, an alternative solution would be to use the network device gadget and run Samba file sharing on the embedded Linux side to export the filesystem where the mmc is mounted on the Linux side.
I am writing a C program in Linux user space for an HMI. I want to detect the pendrive when inserted into the USB port on my SBC. I am running Lubuntu on it. So it is not having udev libraries. When I try to install udev on SBC, it is asking for dependencies and version compatibility issues are coming. Is there any other way to detect the Pendrive insertion from user space.
When I mount a device ex: /dev/sdc1(pendrive) to a particular folder ex: /mnt/vj, its being mounted properly. If I remove the pendrive without unmounting it then when next time pendrive inserted its being detected as /dev/sdd1 . How to fix the logical name for a pendrive in such cases. I want it to be /dev/sdc1 always. Is it possible?
Thanks in anticipation.
You can implement your own event listening daemon instead of udev. Youhave to create a netlink socket of type NETLINK_KOBJECT_UEVENT. By parsing the events, you will be able to detect the insertion of your drive.
It is not possible to ensure the name is always the same but you can probably create a symlink to the proper block device after detecting the event.
Check the link ubuntu 12.04 libudev-dev won't install because of dependencies that should mostly resolve your udev installation/dependencies issue if related to it.
udev is one of the easiest ways for detecting hardware plug-in and fetching of device information. Checkout libudev that is part of udev (Device manager of Linux kernel). Apart from managing device nodes in the /dev directory while hardware devices are added into the system or removed from it, the udev also handles all related user-space events that are raised during various operations such as addition/removal.
libudev allows access to device information and also provides a monitoring interface like udev_monitor that connects to device event source. udev_monitor_get_fd provides file descriptor that can be used with select system call for monitoring.
Check this link that has information related to usage of libudev http://www.signal11.us/oss/udev/
I have a custom am335x based board which I am able to boot via uart booting. I have developed a small initramfs that boots buildroot standard image and mounts the emmc and my script runs fdisk commands at boot to partition the emmc. I would like to know
How to make the target board mount the emmc on my pc via the usb so that I can transfer the actual files on to the emmc.
What services / tools do I need to put on the target.
Can I do it via buildroot itself?
Is there a way to make fastboot work on the linux on the target board?
This might seem like a stupid question but...
After using a USB to install Ubuntu, is it possible to use it as a regular USB again or is it like a CD install and the USB is now only good for installing Ubuntu?
Thanks.
Yes you can.
Infact you can keep the Ubuntu setup as it is and use the remaining free space to store other things, just incase you need Ubuntu installation in future.
You can use it normally, just be sure you have cleaned up the MBR for the case you leave the device plugged in at restart (when USB boot is still enabled).
Easiest is to format the whole partition (or use a partition manager to clean up the whole device). GParted should be able to do this for you.
Some (sketchy!) technical background:
The USB device is a flash device, where bits are stored non-volatile, but eraseable and changeable. Bits at a normal CD-ROM will really be "burned" in as the reflection capacity will be permanently changed when creating a CD. When booting up your computer, there is small memory ROM that contains a bootloader, that is looking up for devices containing a MBR at the first 512 bytes, that will be executed and load the OS (or in your case the first steps of the Ubuntu installation process).
So if you want to use the USB device as normal data storage again, you should also clear up these first 512 Bytes, as the bootloader from the USB could be loaded otherwise when leaving the device plugged in at reboot. Then the bootloader could throw an exception, as it would normally expect the Ubuntu installation files to be present onto this device.
Is it possible to mount a ISO image from USB disk and to use it as a filesystem at boot time(with grub)? I ask it because I would like to put the kernel linux image and an ISO to be used as a filesystem(with fedora bootstrap) into an USB disk(without creating new partitions, etc.), as it is possible to do by using Qemu, for example.
Qemu is a virtualization/emulation environment. Grub is a bootloader, designed to get a kernel loaded into memory and start it executing. Neither program is directly related to your question, although you could certainly use Qemu to execute a VM that uses Grub to start Linux to do what you want.
Modern Linux distributions create an initrd, which the bootloader puts into memory for the kernel to use as its initial root file system. The initrd does things like loading the modules necessary to access the hard disks where the real root file system lives. In your case, you should look at having the initrd find your ISO, mount it, and use it as the root.
The contents of initrd vary based on what distro you're using. I'd grab a livecd from somewhere, dump its initrd's contents with zcat /boot/initrd-2.6.whatever.img | cpio -id, and check out what it's doing. Look for the init file, which will be the first user-space process run by the kernel.
Grub's loopback feature should allow you to boot a kernel and initrd from within an ISO image. Unfortunately, there's no way to allow the kernel to mount a loopback device as the root filesystem, so I think you're out of luck.