02-08-2016 12:23 PM
I'm working on a program with a Zynq-7000 booting Ubuntu linux from an SD card. Can somone explain a few things, I'm learning as I go...
I partitioned the SD card per the instructions on the Xilinx Wiki page. I have the following files on the boot partition of the SD:
boot.bin, fsbl.elf, uImage, u-boot.elf, devicetree.dtb and uramdisk.image.gz. Per the instructions on partitioning the SD card, the second partition (root) contains a filesystem that is similar to what the uramdisk.image.gz looks like when uncompressed.
I understand most of the files on the boot partition and have successfully generated the fsbl, the device tree, ect. specific to my hardware platform. My understanding of the uramdisk.image.gz is that it contains the rootfs that is uncompressed and loaded into RAM at boot? What is the filesystem on the root partition used for? Is it even necessary?
My application is running out of resources and I am trying to make the rootfs larger. Additionally, I want to set system limits, like max number of open files, which I have to do from the terminal using ulimit now.
Can somone explain how the rootfs works? I'm reading a lot, but I'm just not getting it. Thanks
02-08-2016 01:04 PM
You have a few more files that strictly necessary -- does not cause any harm, but maybe adding to your confusion. BOOT.BIN is a combination of the FSBL and u-boot (and in some cases, also your FPGA bitstream). The BOOT.BIN is the first thing that loads, then it fetches uImage, devicetree.dtb and uramdisk.image.gz into RAM. Finally it transfers control to the linux kernel (uImage).
Getting all of Ubuntu to fit into a ramdisk would next to impossible (it is a desktop Linux distribution). So to make it work on Zynq, there is a small ramdisk, which is used as a sort of "springboard" on the way to the full Ubuntu, stored on the SD card. The secret sauce occurs during boot:
echo "mount root" /bin/mount /dev/mmcblk0p2 /mnt /bin/mount -t devtmpfs devtmpfs /mnt/dev echo "hand off to new root" # exec /sbin/init exec /sbin/switch_root /mnt /sbin/init
That effectively switches PID=1 (the first user-space process) to be /sbin/init from the 2nd partition (mmcblk0p2).
Your issue with running out of space in /dev (on devtmpfs) is most likely the result of either:
- accidentally copying something large into /dev (possibly because a device driver is missing)
- using an unrealistic number of resources (eg. millions of semaphores, etc).
I would suggest doing a boot from a clean, known good SD card image. Then selectively add your own stuff to it, watching to see at what point devtmpfs usage increases.
02-08-2016 01:17 PM
I've attached my boot log. I do not see this transition to the rootfs on the SD card?
Where are the instructions to do so located?
Our application relies heavily on semaphores and message queues, but it's a working application that is being ported from vxworks, so I would assume that Linux could handle what we are doing...
02-08-2016 01:32 PM
So the bootloader is fetching a ramdisk (in addition to uImage the devicetree):
Copying Linux from SD to RAM... reading uImage 3535152 bytes read in 340 ms (9.9 MiB/s) reading devicetree.dtb 10055 bytes read in 17 ms (577.1 KiB/s) reading uramdisk.image.gz 6172273 bytes read in 583 ms (10.1 MiB/s)
However your kernel is booting directly to the 2nd partition of the SD card (eg. the ramdisk is not used):
Kernel command line: console=ttyPS0,115200 root=/dev/mmcblk1p2
The ramdisk later gets discarded:
Trying to unpack rootfs image as initramfs... Freeing initrd memory: 6028K (dfa1d000 - e0000000)
I do not run Ubuntu myself, so I can't say if this is normal... or if the wiki is just out of date.
Would still recommend a "clean" boot, check the usage of devtmpfs... is it already at 100% or even at 50%? Or does that only happen when you run your application?
One thing I noticed (from your other discussion thread) is that your devtmpfs seems to only be 64 kB. Normally devtmpfs, which is based on tmpfs, can grow to 50% of your total RAM. And indeed, your /tmp is much larger.
So something in the boot up must be limiting the size of the devtmpfs. I'd start by looking in /etc/fstab (does it mention devtmpfs), and does it set a size of 64kB by any chance?
02-08-2016 02:09 PM
I just added the root parameter to the bootargs this afternoon. Here is what the fstab file looks like.
root@zynq:/etc# more fstab
# stock fstab - you probably want to override this with a machine specific one
none /dev/mqueue mqueue defaults 0 0
/dev/root / auto defaults 1 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
usbdevfs /proc/bus/usb usbdevfs noauto 0 0
tmpfs /run tmpfs mode=0755,nodev,nosuid,strictatime 0 0
tmpfs /var/volatile tmpfs defaults 0 0
# uncomment this if your device has a SD/MMC/Transflash slot
#/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0
02-08-2016 02:20 PM
02-08-2016 02:23 PM
I might be confused here, but I put the SD card in the linux host and looked at the fstab file on the root partition. It is vastly different than the one I see on the target board. So, it appears that the filesystem is the ramdisk and not the root partition of the SD card?
02-08-2016 04:26 PM