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?
Related
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???
Suppose we have the Linux OS installed on two identical machines that supports the version of latest Docker. Then suppose we build a container image based on this OS. We can assume this image will now run on either machine. We now put this image onto a USB drive and plug it in the other identical machine.
Now, the hard part... is it possible, using that image on the USB drive to run the container on the same USB drive itself while plugged into the machine?
I'm trying to save and/or minimize memory used by the host OS by utilizing the memory on the USB drive as much as possible.
If this is possible, how would I go about setting up a demo case?
I see this question as "how do I persist Docker data on a USB device?".
On your machines, you need to mount your USB device into /var/docker. And then restart your Docker service.
However, with this solution, when you unplug the USB device, all of the containers have to be stopped. Otherwise, data will be lost.
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 currently have a raspberry pi, and am using my sd card to boot into linux for on-the-go access. However, the sd card boots into an ubuntu x86 version, not ARM. I saw the tutorial on how to flash the sd card for a raspberry pi, but I was curious if there is a way to pick which OS with specific architecture to boot off of. Is there a way to choose whichever system you would like to boot from?
Your SD card currently allow you to boot on ubuntu x86. You just want to add the ability to boot on your RPi. This totally depends on the ability of the RPi. I can't find complete documentation on RPi processor (this is why I don't like RPi (and Broadcom)), but, according to some online documentation, the RPi boots on FAT32. Your PC is probably also able to boot on a FAT32-formated SD card.
So, if your SD card format fits RPi requirements, you may put your bootable ubuntu x86 and a RPi bootloader on the same SD card partition. RPi is baremetal ARM, so you may put anything you want in your bootloader, including looking for your kernel on FAT32 on SD card with any name you want. It is therefore possible to add your ARM bootloader, your ARM kernel, and an ARM ramfs on your SD card without interfering with the x86 related files. You may then add a partition on your SD card to put your ARM binaries (some will use the same name as the x86, such as bash or startx, and should not be put on the same location than x86 ones, to avoid conflicts), and share data partitions between x86 and ARM OS.