Is my petalinux image too big?

[Boscoe]

Hi all,

I'm having a little confusing time with my custom Zynq 7000 based petalinux attempts. I have 256MiB of DDR3 which is verified passing the DRAM tests that are included in the Vitis examples, the eye width and position seem acceptable at 65% in the worst case condition.

I built a petalinux with some extra packages such as build-essentials, USB gadget CDC and a couple of others.

I get the error below when trying to boot the petalinux image. ChatGPT says this is because I've ran out of memory the ls -l for the images directory is below as well. I see rootfs.cpio is at ~254MB. How do I determine the total image size? Is it too large? Could anyone give any tips on what's happening here?

Many thanks!

Code: [Select]

test@testserver ~/p/camera> ls -l images/linux/
total 1289192
-rw-r--r-- 1 test test      3473 Mar 29 06:51 boot.scr
-rw-r--r-- 1 test test      7819 Mar 29 07:40 config
-rw-r--r-- 1 test test 105740524 Mar 29 08:43 image.ub
drwxr-xr-x 2 test test      4096 Mar 29 06:51 pxelinux.cfg/
-rw-r--r-- 1 test test 254417920 Mar 29 07:46 rootfs.cpio
-rw-r--r-- 1 test test 101047751 Mar 29 07:46 rootfs.cpio.gz
-rw-r--r-- 1 test test 101047815 Mar 29 07:46 rootfs.cpio.gz.u-boot
-rw-r--r-- 1 test test 479718400 Mar 29 07:46 rootfs.ext4
-rw-r--r-- 1 test test 127139840 Mar 29 07:46 rootfs.jffs2
-rw-r--r-- 1 test test     29423 Mar 29 07:46 rootfs.manifest
-rw-r--r-- 1 test test 111851662 Mar 29 07:46 rootfs.tar.gz
-rw-r--r-- 1 test test   4045671 Mar 28 17:06 system.bit
-rw-r--r-- 1 test test     18574 Mar 29 07:43 system.dtb
-rwxr-xr-x 1 test test   1018400 Mar 29 07:45 u-boot.bin*
-rw-r--r-- 1 test test   1036974 Mar 29 07:45 u-boot-dtb.bin
-rw-r--r-- 1 test test   1102936 Mar 29 07:45 u-boot-dtb.elf
-rwxr-xr-x 1 test test   7906416 Mar 29 07:45 u-boot.elf*
-rw-r--r-- 1 test test   4672120 Mar 29 08:43 uImage
-rw-r--r-- 1 test test  14139644 Mar 29 08:43 vmlinux
-rw-r--r-- 1 test test   4672056 Mar 29 08:43 zImage
-rw-r--r-- 1 test test    473860 Mar 29 07:43 zynq_fsbl.elf


Code: [Select]

kworker/u4:0 invoked oom-killer: gfp_mask=0x140cc2(GFP_HIGHUSER|__GFP_COMP), order=0, oom_score_adj=0
CPU: 1 PID: 7 Comm: kworker/u4:0 Not tainted 6.1.30-xilinx-v2023.2 #1
Hardware name: Xilinx Zynq Platform
Workqueue: events_unbound async_run_entry_fn
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x40/0x4c
 dump_stack_lvl from dump_header+0x5c/0x294
 dump_header from out_of_memory+0x14c/0x380
 out_of_memory from __alloc_pages+0x5e0/0x730
 __alloc_pages from __filemap_get_folio+0x1a8/0x218
 __filemap_get_folio from pagecache_get_page+0x14/0x50
 pagecache_get_page from simple_write_begin+0x1c/0x88
 simple_write_begin from generic_perform_write+0xb8/0x1c8
 generic_perform_write from __generic_file_write_iter+0x134/0x15c
 __generic_file_write_iter from generic_file_write_iter+0x5c/0xe8
 generic_file_write_iter from __kernel_write_iter+0xcc/0x100
 __kernel_write_iter from __kernel_write+0x70/0x98
 __kernel_write from kernel_write+0x40/0x54
 kernel_write from xwrite+0x38/0xa0
 xwrite from do_copy+0xe4/0x128
 do_copy from write_buffer+0x24/0x3c
 write_buffer from flush_buffer+0x38/0x98
 flush_buffer from __gunzip+0x2c4/0x328
 __gunzip from gunzip+0x28/0x30
 gunzip from unpack_to_rootfs+0x1c4/0x2a8
 unpack_to_rootfs from do_populate_rootfs+0x64/0x16c
 do_populate_rootfs from async_run_entry_fn+0x20/0xa8
 async_run_entry_fn from process_one_work+0x138/0x1e8
 process_one_work from worker_thread+0x184/0x258
 worker_thread from kthread+0xf0/0xf8
 kthread from ret_from_fork+0x14/0x2c
Exception stack(0xd0831fb0 to 0xd0831ff8)
1fa0:                                     00000000 00000000 00000000 00000000
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Mem-Info:
active_anon:0 inactive_anon:0 isolated_anon:0
 active_file:0 inactive_file:0 isolated_file:0
 unevictable:30910 dirty:0 writeback:0
 slab_reclaimable:689 slab_unreclaimable:676
 mapped:0 shmem:0 pagetables:0
 sec_pagetables:0 bounce:0
 kernel_misc_reclaimable:0
 free:4399 free_pcp:31 free_cma:4030
Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:123640kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB kernel_stack:344kB pagetables:0kB sec_pagetables:0kB all_unreclaimable? yes
Normal free:17596kB boost:0kB min:1540kB low:1924kB high:2308kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:123652kB writepending:0kB present:262144kB managed:148856kB mlocked:0kB bounce:0kB free_pcp:124kB local_pcp:24kB free_cma:16120kB
lowmem_reserve[]: 0 0 0
Normal: 1*4kB (U) 1*8kB (C) 1*16kB (C) 1*32kB (C) 2*64kB (UC) 2*128kB (UC) 1*256kB (U) 3*512kB (UMC) 1*1024kB (C) 1*2048kB (C) 3*4096kB (C) = 17596kB
30918 total pagecache pages
0 pages in swap cache
Free swap  = 0kB
Total swap = 0kB
65536 pages RAM
0 pages HighMem/MovableOnly
28322 pages reserved
4096 pages cma reserved
Tasks state (memory values in pages):
[  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
Out of memory and no killable processes...
Kernel panic - not syncing: System is deadlocked on memory
CPU0: stopping
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.30-xilinx-v2023.2 #1
Hardware name: Xilinx Zynq Platform
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x40/0x4c
 dump_stack_lvl from do_handle_IPI+0x78/0x138
 do_handle_IPI from ipi_handler+0x14/0x20
 ipi_handler from handle_percpu_devid_irq+0x4c/0xe8
 handle_percpu_devid_irq from handle_irq_desc+0x1c/0x2c
 handle_irq_desc from gic_handle_irq+0x60/0x70
 gic_handle_irq from generic_handle_arch_irq+0x28/0x3c
 generic_handle_arch_irq from __irq_svc+0x88/0xc8
Exception stack(0xc0c01eb8 to 0xc0c01f00)
1ea0:                                                       00000000 00000000
1ec0: 0e28e000 cedcf580 cedce938 f9e2b76c 00000000 00000000 00000001 c0c357e0
1ee0: f8502b37 00000001 00000000 c0c01f08 c0569004 c0569028 600f0013 ffffffff
 __irq_svc from cpuidle_enter_state+0x110/0x27c
 cpuidle_enter_state from cpuidle_enter+0x28/0x38
 cpuidle_enter from do_idle+0x238/0x25c
 do_idle from cpu_startup_entry+0x18/0x1c
 cpu_startup_entry from rest_init+0xb0/0xcc
 rest_init from arch_post_acpi_subsys_init+0x0/0x8
---[ end Kernel panic - not syncing: System is deadlocked on memory ]---

[Foxxz]

So if your filesystem is 254MB and you're loading the whole thing into RAM that means you have 2MB of RAM left for your kernel and userspace programs to execute in. Have you tried a barebones image first? I wouldn't want the image to exceed 64MB initially.

Edited to add - If you are compressing it with gzip consider you need to load the compressed image into RAM + the uncompressed image into RAM. Plus whatever memory the kernel needs. After decompression the compressed image no longer occupies memory and your RAM needs are the filesystem image + kernel + userspace requirements.

[Boscoe]

So if your filesystem is 254MB and you're loading the whole thing into RAM that means you have 2MB of RAM left for your kernel and userspace programs to execute in. Have you tried a barebones image first? I wouldn't want the image to exceed 64MB initially.

Edited to add - If you are compressing it with gzip consider you need to load the compressed image into RAM + the uncompressed image into RAM. Plus whatever memory the kernel needs. After decompression the compressed image no longer occupies memory and your RAM needs are the filesystem image + kernel + userspace requirements.

Hi Foxxz, thank you for this information, this is what I was thinking, too. I enabled a few packages and I'm curious to know which ones take up the memory. Do you know of any tools that can calculate the usage of each package?

[ejeffrey]

build-essentials is pretty big, I doubt you will be able to include that in an image that fits in a ramdisk.

A system with 256 MB of DRAM is going to have a hard time running anything like a complete OS from a ramdisk with room for the kernel and have space left for userspace.  It's certainly possible in a "production" system where you just have your custom program pre-compiled and running on a stripped down system, but if you are trying to add interactive tools and development tools I think you are probably looking for more than that.  If that is what you want you should probably figure out how to use a flash based rootfs.

[Boscoe]

build-essentials is pretty big, I doubt you will be able to include that in an image that fits in a ramdisk.

A system with 256 MB of DRAM is going to have a hard time running anything like a complete OS from a ramdisk with room for the kernel and have space left for userspace.  It's certainly possible in a "production" system where you just have your custom program pre-compiled and running on a stripped down system, but if you are trying to add interactive tools and development tools I think you are probably looking for more than that.  If that is what you want you should probably figure out how to use a flash based rootfs.

Thanks, even this doesn't seem possible in my 16MB of FLASH. Not to worry as I was only really using Linux to test the system.

I did manage to boot Linux on a bare minimum image.

[Foxxz]

build-essentials is pretty big, I doubt you will be able to include that in an image that fits in a ramdisk.

A system with 256 MB of DRAM is going to have a hard time running anything like a complete OS from a ramdisk with room for the kernel and have space left for userspace.  It's certainly possible in a "production" system where you just have your custom program pre-compiled and running on a stripped down system, but if you are trying to add interactive tools and development tools I think you are probably looking for more than that.  If that is what you want you should probably figure out how to use a flash based rootfs.

Thanks, even this doesn't seem possible in my 16MB of FLASH. Not to worry as I was only really using Linux to test the system.

I did manage to boot Linux on a bare minimum image.

Some of my first experience with embedded linux were on systems containing 8MB of flash and 32mb of RAM. It just came down to compiling the kernel to only include what was needed and slimming down the filesystem to the essentials for your task. Many embedded devices use busybox linux.

[ejeffrey]

build-essentials is pretty big, I doubt you will be able to include that in an image that fits in a ramdisk.

A system with 256 MB of DRAM is going to have a hard time running anything like a complete OS from a ramdisk with room for the kernel and have space left for userspace.  It's certainly possible in a "production" system where you just have your custom program pre-compiled and running on a stripped down system, but if you are trying to add interactive tools and development tools I think you are probably looking for more than that.  If that is what you want you should probably figure out how to use a flash based rootfs.

Thanks, even this doesn't seem possible in my 16MB of FLASH. Not to worry as I was only really using Linux to test the system.

I did manage to boot Linux on a bare minimum image.

My kernel image for a ZynqMP system is 16 MB so yeah it may be tricky to slim down to that size starting with petalinux, although the zynq7000 will be smaller. 

The standard boot sequence for Linux uses the initramfs method.  There is a small archive in the CPIO format build into the kernel image.  That is responsible for loading any modules, configuring some hardware, and mounting the root filesystem.  The initramfs on my  petalinux install is only 5 MB.  For a lot of applications you can  just put your executable in the initramfs and never go past that stage.  But this environment is very limited.  It typically has a shell, a few filesystem utilities like mount, a minimal DHCP client for NFS root, and that's it. 

[Forty-Bot]

Just don't load everything into ram. Set your root to e.g. /dev/mmc0blk2 or whatever. You can use an initramfs, but there are only two reasons to do so:

• You want to run fsck on your root partition
• You have to start running some application within X seconds of power on and regular boot is too slow.