search

edison-fw / meta-intel-edison

Here is the meta-intel-edison that builds, tries to stay up to date. Master is based on Yocto Poky Gatesgarth LTS 5.10.yy vanilla kernels. It builds a 32bit kernel (Gatesgarth branch 64bit) with ACPI enabled and corresponding rootfs. Telegram group: https://t.me/IntelEdison Web-site:
https://edison-fw.github.io/meta-intel-edison/
MIT License
60 stars 37 forks source link

edison-image.bb: Generate live image with initramfs kernel #15

Closed alext-mkrs closed 6 years ago

alext-mkrs commented 6 years ago

Here goes my config I came up with after analyzing reasons https://github.com/htot/meta-intel-edison/pull/14 didn't work as expected. There's basically a combination of newer Yocto (different variables) and no direct support for using initramfs kernel for live images. However there is a way and it doesn't even look like [too much of a] a hack to me :) I've added comments to make sure we are able to recall what and why down the road.

Here's how it looks like after generation:

ed@bl-ub$ ll /mnt1
total 11348
drwxr-xr-x  2 root root    16384 Jan  1  1970 ./
drwxr-xr-x 28 root root     4096 Dec 25 21:27 ../
-r-xr-xr-x  1 root root   122308 Dec 25 22:35 ldlinux.c32*
-r-xr-xr-x  1 root root    69632 Dec 25 22:35 ldlinux.sys*
-rwxr-xr-x  1 root root   186500 Dec 25 22:35 libcom32.c32*
-rwxr-xr-x  1 root root    24148 Dec 25 22:35 libutil.c32*
-rwxr-xr-x  1 root root      592 Dec 25 22:35 syslinux.cfg*
-rwxr-xr-x  1 root root    27104 Dec 25 22:35 vesamenu.c32*
-rwxr-xr-x  1 root root 11161872 Dec 25 22:35 vmlinuz*

ed@bl-ub$ ll bzImage--4.14.0-r0-edison-20171210145327.bin 
-rw-r--r-- 2 ed ed 7651600 Dec 10 16:12 bzImage--4.14.0-r0-edison-20171210145327.bin

ed@bl-ub$ ll bzImage-initramfs-4.14.0-r0-edison-20171210145327.bin 
-rw-r--r-- 2 ed ed 11161872 Dec 10 16:12 bzImage-initramfs-4.14.0-r0-edison-20171210145327.bin

By the way, original Edison (release 3.5) image looks like this, just for reference. Looking at the recipe, they disable initrd generation, but at the same time don't use the initramfs kernel.

ed@bl-ub$ ll /mnt
total 5530
drwxr-xr-x  2 root root   16384 Jan  1  1970 ./
drwxr-xr-x 28 root root    4096 Dec 25 21:27 ../
-r-xr-xr-x  1 root root  115472 Dec  3  2016 ldlinux.c32*
-r-xr-xr-x  1 root root   59904 Dec  3  2016 ldlinux.sys*
-rwxr-xr-x  1 root root     198 Dec  3  2016 syslinux.cfg*
-rwxr-xr-x  1 root root 5460640 Dec  3  2016 vmlinuz*
htot commented 6 years ago

Wow. I'll test this. You're right,original kernel did not need initrd or initramfs. We need to do that, to get the order of certain modules right (forgot which one, but possible for the sd card). I choose initramfs because that is what I found first, and it's a bit more convenient (didn't need to think how to u-boot it, only one file to copy). But initrd would probably work to.

htot commented 6 years ago

I built this, fixed up the postbuild script and used Flash Tool Lite (v5.8.4.0) to flash the Edison. Never used that before, but it went well, log file here: flashtoollite.log

I didn't try flashall.sh, maybe you want to try that. For now I'll just assume that works as well and commit this and the other patches.

BTW To be honest, this was with the 32b 4.14 kernel (I switched back to that one, because was testing other stuff and didn't want to rebuild everything).

htot commented 6 years ago

One weird thing:

root@edison:~# df
Filesystem      1K-blocks   Used Available Use% Mounted on
..
/dev/mmcblk0p8     950168 469716    411640  54% /
..
/dev/mmcblk0p10   1337936   2132   1319420   1% /home
/dev/mmcblk0p5       1003     19       913   3% /factory
..
root@edison:~# fdisk -l
Disk /dev/mmcblk0: 3.7 GiB, 3909091328 bytes, 7634944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 21200400-0804-0146-9DCC-A8C51255994F

Device            Start     End Sectors  Size Type
..
/dev/mmcblk0p8   131072 3276799 3145728  1.5G Microsoft basic data
/dev/mmcblk0p9  3276800 4849663 1572864  768M Microsoft basic data
/dev/mmcblk0p10 4849664 7634910 2785247  1.3G Microsoft basic data

root (p8) is 1.5G in size but only 1G is available. That might have something to do with this line in edison-image.bb: IMAGE_ROOTFS_SIZE = "1048576"

htot commented 6 years ago

But for now:

# resize2fs -p /dev/mmcblk0p8
resize2fs 1.43.4 (31-Jan-2017)
Filesystem at /dev/mmcblk0p8 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/mmcblk0p8 is now 393216 (4k) blocks long.

Fixed that.

htot commented 6 years ago

Merged into pyro64