I am developing scripts for my embedded board ( a zynq board) and I need some scripts to be loaded prior to login. Since the filesystem is loaded into DDR memory, any modifications will be erased after a reboot. So for my development, I have to remove the SD card, then mount the filesystem on my development machine and after that, I have to unmount the FS and wrap u-boot headers on top of it. Finally write everything to SD card and see if everything is working or not. I was wondering if there is any better solution??? like reloading file system while linux is running???
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.
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.
I am compiling my own Linux kernel and userland tools for a PXE environment meant for cloning and reimaging. Right now, I'm sticking to a specific kernel version and using preconfigured .config's for building the Linux kernel.
I need to change from using preconfigured .config's to automatically generating the default configuration for the specified architecture, and then enabling all ethernet, ATA, SATA, and SCSI drivers.
The reason I want to do this is:
Updating the kernel means updating the preconfigured .config's, which takes too much time to manually do. The way I'm doing it now is using menuconfig, enabling the options I need, and saving the resulting .config to my repository.
I know the kernel I'm building is missing some drivers because I've encountered some PC's that were not able to mount the NFS share because Linux could not find an ethernet device (which I've verified by booting an Ubuntu CD, which did find the ethernet device). I want an automated way of building any Linux kernel version that will guarantee that ALL drivers I need are pulled in.
Using a distribution's configuration pulls in too many unnecessary drivers and features for my purposes. It lengthens the kernel build time from 10-15 mintues to an hour or more, and the resulting image is too big.
Does anyone know how to write a Bash script to accomplish this?
Have you considered using a text editor to modify the .config file.
Then you can modify it using search and replace.
Plus, there are other choices for configuring the kernel than the menu-driven "menuconfig".
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.
Suppose I've installed Linux on my flash drive. Why do I need something like the casper loop file to make saving persistent? So files are being erased? Isn't the flash drive the same as actual hard disk drive? I'm a Linux noob so be patient.
Or it is because Linux on a flash drive is actually like live CD on a flash drive? Can it be installed just like it is installed on a hard disk drive?
Live Linux off a USB stick is done by embedding a bootable, read-only filesystem image as a file on a USB stick and booting from that. This is done for a couple of reasons, the largest of which being that the stick remain readable / usable on other systems, but also because it means you can use the same stack of files to make a Live CD as a USB stick.
Normally when this is done, the RW portion is done via a ramdisk, however with a USB stick, you have the opportunity to store the mutable portion of the live system on the stick.
You may think, "well, why not just do it as a directory on the stick?" The reason for this is that a FAT32 filesystem doesn't have all the metadata that a Unix environment needs. You need to use something like ext2.
So what is a casper file? It's a file that has been treated like it's a hard drive partition. That's it. Instead of pointing mkfs.ext2 or mount at /dev/sda3 (a partition), you've pointed it at /mnt/sda3/casper-rw (a file).
Casper is basically a storage container for Linux systems which downloads programs/drivers/settings anything that is software based is saved in. The files that are not in the casper drive are either the live cd (which would be on a USB drive in this case) and user-created files such as Open Office documents, pictures, and videos. Don't use up the free space on your USB drive with casper or you won't have room to save documents on the drive.
You can install Linux onto your flash drive which in turn wouldn't need a casper persistent storage because of how it runs, but it renders the USB drive as only usable on the pc that it was installed with.
That's what casper provides because a live USB drive can be used on many pcs with the same hardware configuration as the version you downloaded, and casper brings your programs and settings with you.
It seems like a "no brainer" model in keeping your "Tool"=(OS) & your "Art"=(Data / Documents) isolated from each other, and it could go even farther by "Tool"=(OS) "Special Tools"=(Additional 'wares) & "Art"=(Data / Documents).