zimage Initramfs booting stuck at Start Kernel

zimage Initramfs booting stuck at Start Kernel

[JH]

Hi,

I finally built the
zImage->zImage--4.19.75+git0+d573e8a79f-r0-20191026074920.bin and
zImage-initramfs ->
zImage-initramfs--4.19.75+git0+d573e8a79f-r0-20191026074920.bin based
on oe-core kernel.bbclass.

The zImage could be loaded by u-boot on RAM booting but failed at
mount rootfs which was fine as it did not bundle the rootfs. The
zImage-initramfs bundled to rootfs, but it could not be started and
stuck at u-boot Starting kernel, there was no trace of errors.

Hit any key to stop autoboot:  0
=> bootz ${loadaddr} - ${fdt_addr}
Kernel image @ 0x80800000 [ 0x000000 - 0x219df80 ]
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Using Device Tree in place at 83000000, end 83008831
ft_system_setup for mx6

Starting kernel ...

Because zImage could be started, zImage-initramfs could not, that
implies there were no issues in the u-boot, is must be something wrong
with the zImage-initramfs. Seems debug is harder, are there anyway to
extract information from zImage-initramfs to figure out what is wrong?

Thank you.

Kind regards,

- jh

Re: zimage Initramfs booting stuck at Start Kernel

[Ferry Toth]

Op 26-10-2019 om 11:46 schreef JH:
> Hi,
> 
> I finally built the
> zImage->zImage--4.19.75+git0+d573e8a79f-r0-20191026074920.bin and
> zImage-initramfs ->
> zImage-initramfs--4.19.75+git0+d573e8a79f-r0-20191026074920.bin based
> on oe-core kernel.bbclass.
> 
> The zImage could be loaded by u-boot on RAM booting but failed at
> mount rootfs which was fine as it did not bundle the rootfs. The
> zImage-initramfs bundled to rootfs, but it could not be started and
> stuck at u-boot Starting kernel, there was no trace of errors.
> 
> Hit any key to stop autoboot:  0
> => bootz ${loadaddr} - ${fdt_addr}
> Kernel image @ 0x80800000 [ 0x000000 - 0x219df80 ]
> ## Flattened Device Tree blob at 83000000
>     Booting using the fdt blob at 0x83000000
>     Using Device Tree in place at 83000000, end 83008831
> ft_system_setup for mx6
> 
> Starting kernel ...
> 
> Because zImage could be started, zImage-initramfs could not, that
> implies there were no issues in the u-boot, is must be something wrong
> with the zImage-initramfs. Seems debug is harder, are there anyway to
> extract information from zImage-initramfs to figure out what is wrong?

As an example you might want to look at my repo, I have 2 images minimal 
and initramfs:
https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core/images

I don't exactly know how you are doing it. But I'll try to explain what 
I do:
I have
1) a normal rootfs (say edison-image-minimal) and
2) a initramfs rootfs containing kernel modules needed for booting and a 
init script.

Initramfs is build using core-image-minimal-initramfs.bbappend. Some 
additional unneeded packages are pulled, and as size is restricted (10MB 
or so?) we remove them here.

The init script is here: 
https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/initrdscripts/initramfs-framework/init

The init script loads modules, waits for the disk with the rootfs to 
appear and mount it. Then switchroot to it.
If it doesn't appear it drops to a shell so you can investigate what's 
wrong.

To build everything edison-image-minimal triggers build of u-boot, 
kernel, rootfs, initramfs and kernel-with-built-in-initramfs.

Search for 'init' and 'live' and find the needed lines in 
https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/images/edison-image-minimal.bb

> Thank you.
> 
> Kind regards,
> 
> - jh
> 

Re: zimage Initramfs booting stuck at Start Kernel

[JH]

Hi Ferry,

On 10/27/19, Ferry Toth <fntoth@gmail.com> wrote:
>
> As an example you might want to look at my repo, I have 2 images minimal
> and initramfs:
> https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core/images
>
> I don't exactly know how you are doing it. But I'll try to explain what
> I do:
> I have
> 1) a normal rootfs (say edison-image-minimal) and
> 2) a initramfs rootfs containing kernel modules needed for booting and a
> init script.
>
> Initramfs is build using core-image-minimal-initramfs.bbappend. Some
> additional unneeded packages are pulled, and as size is restricted (10MB
> or so?) we remove them here.

Thanks for the tips, that confirms my long suspensions that the size
of the image could be the cause of the problem, my working zImage size
is 8MB, my failing zImager-initramfs size is 35MB. How did you remove
the 10 MB size restriction? I checked your
core-image-minimal-initramfs.bbappend, there is no sign to remove 10
MB size restriction. You have a resize-rootfs.service, but I am not
sure that is the one for fixing the 10 MB size restriction. The
edison-image-minimal.bb has the IMAGE_ROOTFS_SIZE = "1048576", sorry
for my dumb, is that size for 1048576 KB (1GB) or 1048576 B (1MB)?

> The init script is here:
> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/initrdscripts/initramfs-framework/init
>
> The init script loads modules, waits for the disk with the rootfs to
> appear and mount it. Then switchroot to it.
> If it doesn't appear it drops to a shell so you can investigate what's
> wrong.

I am confident that the 10 MB size restriction is the problem, I am
not clear where that 10 MB size restriction is defined and how to fix
the size restriction, appreciate your helps.

> To build everything edison-image-minimal triggers build of u-boot,
> kernel, rootfs, initramfs and kernel-with-built-in-initramfs.

> Search for 'init' and 'live' and find the needed lines in
> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/images/edison-image-minimal.bb

I looked at the init script, but not clear if it is critical for
fixing that issue or not. My init is the symblic link to
/lib/systemd/systemd in imx6.

Thank you very much.

Kind regards,

- jh

Re: zimage Initramfs booting stuck at Start Kernel

[Ferry Toth]

Op 27-10-2019 om 02:27 schreef JH:
> Hi Ferry,
> 
> On 10/27/19, Ferry Toth <fntoth@gmail.com> wrote:
>>
>> As an example you might want to look at my repo, I have 2 images minimal
>> and initramfs:
>> https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core/images
>>
>> I don't exactly know how you are doing it. But I'll try to explain what
>> I do:
>> I have
>> 1) a normal rootfs (say edison-image-minimal) and
>> 2) a initramfs rootfs containing kernel modules needed for booting and a
>> init script.
>>
>> Initramfs is build using core-image-minimal-initramfs.bbappend. Some
>> additional unneeded packages are pulled, and as size is restricted (10MB
>> or so?) we remove them here.
> 
> Thanks for the tips, that confirms my long suspensions that the size
> of the image could be the cause of the problem, my working zImage size
> is 8MB, my failing zImager-initramfs size is 35MB. How did you remove
> the 10 MB size restriction? I checked your

I don't. I reduce the contents as much as possible.

> core-image-minimal-initramfs.bbappend, there is no sign to remove 10
> MB size restriction. You have a resize-rootfs.service, but I am not
> sure that is the one for fixing the 10 MB size restriction. The

No, it isn't.

> edison-image-minimal.bb has the IMAGE_ROOTFS_SIZE = "1048576", sorry
> for my dumb, is that size for 1048576 KB (1GB) or 1048576 B (1MB)?

The rootfs is on disk (/) and is 1GB. It has nothing to do with initramfs.

>> The init script is here:
>> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/initrdscripts/initramfs-framework/init
>>
>> The init script loads modules, waits for the disk with the rootfs to
>> appear and mount it. Then switchroot to it.
>> If it doesn't appear it drops to a shell so you can investigate what's
>> wrong.
> 
> I am confident that the 10 MB size restriction is the problem, I am
> not clear where that 10 MB size restriction is defined and how to fix
> the size restriction, appreciate your helps.

I am not sure where it comes from, I think internal in the kernel there 
is a limit, after uncompress. Initramfs is in ram, I think we just need 
to accept there is a size restriction.

>> To build everything edison-image-minimal triggers build of u-boot,
>> kernel, rootfs, initramfs and kernel-with-built-in-initramfs.
> 
>> Search for 'init' and 'live' and find the needed lines in
>> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/images/edison-image-minimal.bb
> 
> I looked at the init script, but not clear if it is critical for
> fixing that issue or not. My init is the symblic link to
> /lib/systemd/systemd in imx6.

Given the size restriction I think we have no choice to use initramfs to 
load minimum required modules and then mount and switchroot to a file 
system on disk. So, yes, you need to modify init for that. After 
switchroot there will be a new init, the symbolic link you mention.

> Thank you very much.
> 
> Kind regards,
> 
> - jh
> 

Re: zimage Initramfs booting stuck at Start Kernel

[JH]

Hi Ferry,

On 10/27/19, Ferry Toth <fntoth@gmail.com> wrote:
> Op 27-10-2019 om 02:27 schreef JH:
>> Hi Ferry,
>>
>> On 10/27/19, Ferry Toth <fntoth@gmail.com> wrote:
>>>
>>> As an example you might want to look at my repo, I have 2 images minimal
>>> and initramfs:
>>> https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core/images
>>>
>>> I don't exactly know how you are doing it. But I'll try to explain what
>>> I do:
>>> I have
>>> 1) a normal rootfs (say edison-image-minimal) and
>>> 2) a initramfs rootfs containing kernel modules needed for booting and a
>>> init script.
>>>
>>> Initramfs is build using core-image-minimal-initramfs.bbappend. Some
>>> additional unneeded packages are pulled, and as size is restricted (10MB
>>> or so?) we remove them here.
>>
>> Thanks for the tips, that confirms my long suspensions that the size
>> of the image could be the cause of the problem, my working zImage size
>> is 8MB, my failing zImager-initramfs size is 35MB. How did you remove
>> the 10 MB size restriction? I checked your
>
> I don't. I reduce the contents as much as possible.

That is not practical, we cannot limit the kernel + rootfs to 10 MB size.

>> core-image-minimal-initramfs.bbappend, there is no sign to remove 10
>> MB size restriction. You have a resize-rootfs.service, but I am not
>> sure that is the one for fixing the 10 MB size restriction. The
>
> No, it isn't.
>
>> edison-image-minimal.bb has the IMAGE_ROOTFS_SIZE = "1048576", sorry
>> for my dumb, is that size for 1048576 KB (1GB) or 1048576 B (1MB)?
>
> The rootfs is on disk (/) and is 1GB. It has nothing to do with initramfs.

OK.

>>> The init script is here:
>>> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/initrdscripts/initramfs-framework/init
>>>
>>> The init script loads modules, waits for the disk with the rootfs to
>>> appear and mount it. Then switchroot to it.
>>> If it doesn't appear it drops to a shell so you can investigate what's
>>> wrong.
>>
>> I am confident that the 10 MB size restriction is the problem, I am
>> not clear where that 10 MB size restriction is defined and how to fix
>> the size restriction, appreciate your helps.
>
> I am not sure where it comes from, I think internal in the kernel there
> is a limit, after uncompress. Initramfs is in ram, I think we just need
> to accept there is a size restriction.

No, there is no limitation in kernel, BTW, the zImage-initramfs is not
just kernel space, the zImage-initramfs = kernel + rootfs which cannot
be limited to 10 MB. I have a zImage-initramfs created by openwrt, the
size is 28 MB. The problem is created by oe-core, most likely in
kernel.bbclass, could anyone in oe-core development provide insights
where is the 10 MB limitation from and how to fix it?

>>> To build everything edison-image-minimal triggers build of u-boot,
>>> kernel, rootfs, initramfs and kernel-with-built-in-initramfs.
>>
>>> Search for 'init' and 'live' and find the needed lines in
>>> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/images/edison-image-minimal.bb
>>
>> I looked at the init script, but not clear if it is critical for
>> fixing that issue or not. My init is the symblic link to
>> /lib/systemd/systemd in imx6.
>
> Given the size restriction I think we have no choice to use initramfs to
> load minimum required modules and then mount and switchroot to a file
> system on disk. So, yes, you need to modify init for that. After
> switchroot there will be a new init, the symbolic link you mention.

That is not good, we need to fix it. I am still new to oe-core,
bitbake and Yocto, but I am happy to give a try if someone could point
me where could be the source for the 10 MB limitation of
zImage-initramfs.

Thank you very much.

Kind regards,

- jh

Re: zimage Initramfs booting stuck at Start Kernel

[Ferry Toth]

Op 27-10-2019 om 22:52 schreef JH:
> Hi Ferry,
> 
> On 10/27/19, Ferry Toth <fntoth@gmail.com> wrote:
>> Op 27-10-2019 om 02:27 schreef JH:
>>> Hi Ferry,
>>>
>>> On 10/27/19, Ferry Toth <fntoth@gmail.com> wrote:
>>>>
>>>> As an example you might want to look at my repo, I have 2 images minimal
>>>> and initramfs:
>>>> https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core/images
>>>>
>>>> I don't exactly know how you are doing it. But I'll try to explain what
>>>> I do:
>>>> I have
>>>> 1) a normal rootfs (say edison-image-minimal) and
>>>> 2) a initramfs rootfs containing kernel modules needed for booting and a
>>>> init script.
>>>>
>>>> Initramfs is build using core-image-minimal-initramfs.bbappend. Some
>>>> additional unneeded packages are pulled, and as size is restricted (10MB
>>>> or so?) we remove them here.
>>>
>>> Thanks for the tips, that confirms my long suspensions that the size
>>> of the image could be the cause of the problem, my working zImage size
>>> is 8MB, my failing zImager-initramfs size is 35MB. How did you remove
>>> the 10 MB size restriction? I checked your
>>
>> I don't. I reduce the contents as much as possible.
> 
> That is not practical, we cannot limit the kernel + rootfs to 10 MB size.
> 
>>> core-image-minimal-initramfs.bbappend, there is no sign to remove 10
>>> MB size restriction. You have a resize-rootfs.service, but I am not
>>> sure that is the one for fixing the 10 MB size restriction. The
>>
>> No, it isn't.
>>
>>> edison-image-minimal.bb has the IMAGE_ROOTFS_SIZE = "1048576", sorry
>>> for my dumb, is that size for 1048576 KB (1GB) or 1048576 B (1MB)?
>>
>> The rootfs is on disk (/) and is 1GB. It has nothing to do with initramfs.
> 
> OK.
> 
>>>> The init script is here:
>>>> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/initrdscripts/initramfs-framework/init
>>>>
>>>> The init script loads modules, waits for the disk with the rootfs to
>>>> appear and mount it. Then switchroot to it.
>>>> If it doesn't appear it drops to a shell so you can investigate what's
>>>> wrong.
>>>
>>> I am confident that the 10 MB size restriction is the problem, I am
>>> not clear where that 10 MB size restriction is defined and how to fix
>>> the size restriction, appreciate your helps.
>>
>> I am not sure where it comes from, I think internal in the kernel there
>> is a limit, after uncompress. Initramfs is in ram, I think we just need
>> to accept there is a size restriction.
> 
> No, there is no limitation in kernel, BTW, the zImage-initramfs is not
> just kernel space, the zImage-initramfs = kernel + rootfs which cannot
> be limited to 10 MB. I have a zImage-initramfs created by openwrt, the
> size is 28 MB. The problem is created by oe-core, most likely in
> kernel.bbclass, could anyone in oe-core development provide insights
> where is the 10 MB limitation from and how to fix it?

I see that Ubuntu keeps the initramfs in a separate cpio, while we are 
trying to build the cpio into the kernel (afaiu the cpio is unpacked 
into a kernel directory, and then built-in by the kernels build system).

And that cpio is ~64MB, so it must be possible.

In my case kernel, cpio and zImage-initramfs are all built. And although 
U-Boot allows to load kernel and cpio separately I didn't try (or don't 
remember the result). So, maybe that's the trick.

>>>> To build everything edison-image-minimal triggers build of u-boot,
>>>> kernel, rootfs, initramfs and kernel-with-built-in-initramfs.
>>>
>>>> Search for 'init' and 'live' and find the needed lines in
>>>> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-distro/recipes-core/images/edison-image-minimal.bb
>>>
>>> I looked at the init script, but not clear if it is critical for
>>> fixing that issue or not. My init is the symblic link to
>>> /lib/systemd/systemd in imx6.
>>
>> Given the size restriction I think we have no choice to use initramfs to
>> load minimum required modules and then mount and switchroot to a file
>> system on disk. So, yes, you need to modify init for that. After
>> switchroot there will be a new init, the symbolic link you mention.
> 
> That is not good, we need to fix it. I am still new to oe-core,
> bitbake and Yocto, but I am happy to give a try if someone could point
> me where could be the source for the 10 MB limitation of
> zImage-initramfs.
> 
> Thank you very much.
> 
> Kind regards,
> 
> - jh
> 

Re: zimage Initramfs booting stuck at Start Kernel

[JH]

On 10/28/19, Ferry Toth <fntoth@gmail.com> wrote:
>> No, there is no limitation in kernel, BTW, the zImage-initramfs is not
>> just kernel space, the zImage-initramfs = kernel + rootfs which cannot
>> be limited to 10 MB. I have a zImage-initramfs created by openwrt, the
>> size is 28 MB. The problem is created by oe-core, most likely in
>> kernel.bbclass, could anyone in oe-core development provide insights
>> where is the 10 MB limitation from and how to fix it?
>
> I see that Ubuntu keeps the initramfs in a separate cpio, while we are
> trying to build the cpio into the kernel (afaiu the cpio is unpacked
> into a kernel directory, and then built-in by the kernels build system).

I built all package formats, rootfs.tar.gz, rootfs.cpio.gz,
rootfs.cpio.gz.u-boot, zImage->zImage*.bin,
zImage-initramfs->zImage-initramfs*.bin.

I did try to run different images to boot it to imx6 RAM, but the
zImage*.bin (8MB) is the only one I could boot it to imx6 RAM,
obviously it failed to mount rootfs as it did not bundle the rootfs.

How did you build the cpio into the kernel?

> And that cpio is ~64MB, so it must be possible.

Is the 64MB for compressed cpio.gz? If so, that should be fine. Did
you allude that 64MB is also a limitation for cpio?

> In my case kernel, cpio and zImage-initramfs are all built. And although
> U-Boot allows to load kernel and cpio separately I didn't try (or don't
> remember the result). So, maybe that's the trick.

Both rootfs.cpio.gz and rootfs.cpio.gz.u-boot I built are gzip
compressed data, thaI cannot be booted to imx6 RAM.

Here is the image format built from openwrt which I could boot to imx6 RAM:

0             0x0             Linux kernel ARM boot executable zImage
(little-endian)
15464         0x3C68          xz compressed data
15696         0x3D50          xz compressed data

Here is the zImage (8MB) image format I build from bitbake which did
not bundle rootfs, but it could be booted to imx6 RAM

0             0x0             Linux kernel ARM boot executable zImage
(little-endian)
6904          0x1AF8          LZO compressed data
7316          0x1C94          LZO compressed data
7918          0x1EEE          device tree image (dtb)
57505         0xE0A1          device tree image (dtb)
312284        0x4C3DC         LZ4 compressed data, legacy
2049118       0x1F445E        SHA256 hash constants, little endian
2372712       0x243468        mcrypt 2.5 encrypted data, algorithm:
"]", keysize: 23701 bytes, mode: "(",
6093219       0x5CF9A3        device tree image (dtb)
8127047       0x7C0247        LZ4 compressed data, legacy

Here is the zImage-initramfs (35 MB) I build from bitbake which
bundled the rootfs, but could not be booted I believe the cause is the
size too large:

0             0x0             Linux kernel ARM boot executable zImage
(little-endian)
6904          0x1AF8          LZO compressed data
7316          0x1C94          LZO compressed data
7918          0x1EEE          device tree image (dtb)
57505         0xE0A1          device tree image (dtb)
312302        0x4C3EE         LZ4 compressed data, legacy
2049266       0x1F44F2        SHA256 hash constants, little endian
2372864       0x243500        mcrypt 2.5 encrypted data, algorithm:
"]", keysize: 23701 bytes, mode: "(",
6093526       0x5CFAD6        device tree image (dtb)
8127489       0x7C0401        LZ4 compressed data, legacy
10886101      0xA61BD5        ZBOOT firmware header, header size: 32
bytes, load address: 0x0564F721, start address: 0x2E4CEE95, checksum:
0x22771426, version: 0x1D216514, image size: 185068065 bytes
11990008      0xB6F3F8        mcrypt 2.5 encrypted data, algorithm:
">", keysize: 2093 bytes, mode: "-",
12899061      0xC4D2F5        LZMA compressed data, properties: 0x63,
dictionary size: 2097152 bytes, uncompressed size: 139006573920 bytes
12899237      0xC4D3A5        LZMA compressed data, properties: 0x6C,
dictionary size: 2097152 bytes, uncompressed size: 541203680 bytes
12899272      0xC4D3C8        LZMA compressed data, properties: 0x63,
dictionary size: 2097152 bytes, uncompressed size: 139810176352 bytes
12899719      0xC4D587        LZMA compressed data, properties: 0x65,
dictionary size: 2097152 bytes, uncompressed size: 541990112 bytes
12940308      0xC57414        LZMA compressed data, properties: 0x5E,
dictionary size: 522190848 bytes, uncompressed size: 2157628 bytes
12945629      0xC588DD        LZMA compressed data, properties: 0xBE,
dictionary size: -1108672512 bytes, uncompressed size: 138831226112
bytes
12948853      0xC59575        LZMA compressed data, properties: 0xC0,
dictionary size: -551550976 bytes, uncompressed size: 2117660 bytes
12995870      0xC64D1E        Copyright string: "Copyright 2017, NXP"
13729894      0xD18066        ELF, 32-bit LSB processor-specific,
14855286      0xE2AC76        mcrypt 2.5 encrypted data, algorithm:
"9n", keysize: 2452 bytes, mode: "4",
14956131      0xE43663        ELF, 32-bit LSB processor-specific, ("")
15462188      0xEBEF2C        device tree image (dtb)
15506348      0xEC9BAC        device tree image (dtb)
15760959      0xF07E3F        LZ4 compressed data, legacy
17497877      0x10AFF15       SHA256 hash constants, little endian
17821483      0x10FEF2B       mcrypt 2.5 encrypted data, algorithm:
"]", keysize: 23701 bytes, mode: "(",
21542158      0x148B50E       device tree image (dtb)
23402211      0x16516E3       LZ4 compressed data, legacy
23899460      0x16CAD44       mcrypt 2.5 encrypted data, algorithm:
")}", keysize: 11556 bytes, mode: "|",
25538245      0x185AEC5       PARity archive data - file number 13345
25763629      0x1891F2D       mcrypt 2.5 encrypted data, algorithm:
"*l", keysize: 20516 bytes, mode: "~",
26601909      0x195E9B5       SHA256 hash constants, little endian
27027026      0x19C6652       SHA256 hash constants, little endian
27294589      0x1A07B7D       ELF, 32-bit LSB processor-specific, ("")
27377983      0x1A1C13F       mcrypt 2.5 encrypted data, algorithm:
"ute0^", keysize: 25971 bytes, mode: """,
27653793      0x1A5F6A1       Base64 standard index table
28982449      0x1BA3CB1       ELF, 32-bit LSB processor-specific, ("")
29102151      0x1BC1047       LZMA compressed data, properties: 0xB7,
dictionary size: 1572864 bytes, uncompressed size: 106573083904 bytes
30170892      0x1CC5F0C       SHA256 hash constants, little endian
31079699      0x1DA3D13       lrzip compressed data
31079703      0x1DA3D17       LZ4 compressed data
31079707      0x1DA3D1B       LZ4 compressed data, legacy
31081483      0x1DA440B       EBML file
31165137      0x1DB8AD1       lrzip compressed data
31165149      0x1DB8ADD       LZ4 compressed data
31165156      0x1DB8AE4       LZ4 compressed data, legacy
31167662      0x1DB94AE       Gameboy ROM,
31168529      0x1DB9811       EBML file
31273481      0x1DD3209       lrzip compressed data
31273482      0x1DD320A       rzip compressed data - version 32.-20
(-1785336650 bytes)
31552610      0x1E17462       gzip compressed data, from FAT
filesystem (MS-DOS, OS/2, NT), last modified: 1970-01-01 00:01:36
(bogus date)
32680766      0x1F2AB3E       eCos RTOS string reference: "ECOS field"
33863073      0x204B5A1       mcrypt 2.5 encrypted data, algorithm:
"_fd", keysize: 8881 bytes, mode: "h",
34075614      0x207F3DE       ELF, 32-bit LSB processor-specific, ("")
34638178      0x2108962       Copyright string: "copyrighted by many
authors between 1998-2015."
34664157      0x210EEDD       SHA256 hash constants, little endian

Could anyone share insights how to fix it or if there is a workarounds?

Thanks Ferry.

Kind regards,

- jh

Re: zimage Initramfs booting stuck at Start Kernel

[Ferry Toth]

Op 28-10-2019 om 03:02 schreef JH:
> On 10/28/19, Ferry Toth <fntoth@gmail.com> wrote:
>>> No, there is no limitation in kernel, BTW, the zImage-initramfs is not
>>> just kernel space, the zImage-initramfs = kernel + rootfs which cannot
>>> be limited to 10 MB. I have a zImage-initramfs created by openwrt, the
>>> size is 28 MB. The problem is created by oe-core, most likely in
>>> kernel.bbclass, could anyone in oe-core development provide insights
>>> where is the 10 MB limitation from and how to fix it?
>>
>> I see that Ubuntu keeps the initramfs in a separate cpio, while we are
>> trying to build the cpio into the kernel (afaiu the cpio is unpacked
>> into a kernel directory, and then built-in by the kernels build system).
> 
> I built all package formats, rootfs.tar.gz, rootfs.cpio.gz,
> rootfs.cpio.gz.u-boot, zImage->zImage*.bin,
> zImage-initramfs->zImage-initramfs*.bin.
> 
> I did try to run different images to boot it to imx6 RAM, but the
> zImage*.bin (8MB) is the only one I could boot it to imx6 RAM,
> obviously it failed to mount rootfs as it did not bundle the rootfs.
> 
> How did you build the cpio into the kernel?

https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-bsp/conf/machine/edison.conf

And there is the max size!

>> And that cpio is ~64MB, so it must be possible.
> 
> Is the 64MB for compressed cpio.gz? If so, that should be fine. Did
> you allude that 64MB is also a limitation for cpio?

No I don't think so.

>> In my case kernel, cpio and zImage-initramfs are all built. And although
>> U-Boot allows to load kernel and cpio separately I didn't try (or don't
>> remember the result). So, maybe that's the trick.
> 
> Both rootfs.cpio.gz and rootfs.cpio.gz.u-boot I built are gzip
> compressed data, thaI cannot be booted to imx6 RAM.
> 
> Here is the image format built from openwrt which I could boot to imx6 RAM:
> 
> 0             0x0             Linux kernel ARM boot executable zImage
> (little-endian)
> 15464         0x3C68          xz compressed data
> 15696         0x3D50          xz compressed data
> 
> Here is the zImage (8MB) image format I build from bitbake which did
> not bundle rootfs, but it could be booted to imx6 RAM
> 
> 0             0x0             Linux kernel ARM boot executable zImage
> (little-endian)
> 6904          0x1AF8          LZO compressed data
> 7316          0x1C94          LZO compressed data
> 7918          0x1EEE          device tree image (dtb)
> 57505         0xE0A1          device tree image (dtb)
> 312284        0x4C3DC         LZ4 compressed data, legacy
> 2049118       0x1F445E        SHA256 hash constants, little endian
> 2372712       0x243468        mcrypt 2.5 encrypted data, algorithm:
> "]", keysize: 23701 bytes, mode: "(",
> 6093219       0x5CF9A3        device tree image (dtb)
> 8127047       0x7C0247        LZ4 compressed data, legacy
> 
> Here is the zImage-initramfs (35 MB) I build from bitbake which
> bundled the rootfs, but could not be booted I believe the cause is the
> size too large:
> 
> 0             0x0             Linux kernel ARM boot executable zImage
> (little-endian)
> 6904          0x1AF8          LZO compressed data
> 7316          0x1C94          LZO compressed data
> 7918          0x1EEE          device tree image (dtb)
> 57505         0xE0A1          device tree image (dtb)
> 312302        0x4C3EE         LZ4 compressed data, legacy
> 2049266       0x1F44F2        SHA256 hash constants, little endian
> 2372864       0x243500        mcrypt 2.5 encrypted data, algorithm:
> "]", keysize: 23701 bytes, mode: "(",
> 6093526       0x5CFAD6        device tree image (dtb)
> 8127489       0x7C0401        LZ4 compressed data, legacy
> 10886101      0xA61BD5        ZBOOT firmware header, header size: 32
> bytes, load address: 0x0564F721, start address: 0x2E4CEE95, checksum:
> 0x22771426, version: 0x1D216514, image size: 185068065 bytes
> 11990008      0xB6F3F8        mcrypt 2.5 encrypted data, algorithm:
> ">", keysize: 2093 bytes, mode: "-",
> 12899061      0xC4D2F5        LZMA compressed data, properties: 0x63,
> dictionary size: 2097152 bytes, uncompressed size: 139006573920 bytes
> 12899237      0xC4D3A5        LZMA compressed data, properties: 0x6C,
> dictionary size: 2097152 bytes, uncompressed size: 541203680 bytes
> 12899272      0xC4D3C8        LZMA compressed data, properties: 0x63,
> dictionary size: 2097152 bytes, uncompressed size: 139810176352 bytes
> 12899719      0xC4D587        LZMA compressed data, properties: 0x65,
> dictionary size: 2097152 bytes, uncompressed size: 541990112 bytes
> 12940308      0xC57414        LZMA compressed data, properties: 0x5E,
> dictionary size: 522190848 bytes, uncompressed size: 2157628 bytes
> 12945629      0xC588DD        LZMA compressed data, properties: 0xBE,
> dictionary size: -1108672512 bytes, uncompressed size: 138831226112
> bytes
> 12948853      0xC59575        LZMA compressed data, properties: 0xC0,
> dictionary size: -551550976 bytes, uncompressed size: 2117660 bytes
> 12995870      0xC64D1E        Copyright string: "Copyright 2017, NXP"
> 13729894      0xD18066        ELF, 32-bit LSB processor-specific,
> 14855286      0xE2AC76        mcrypt 2.5 encrypted data, algorithm:
> "9n", keysize: 2452 bytes, mode: "4",
> 14956131      0xE43663        ELF, 32-bit LSB processor-specific, ("")
> 15462188      0xEBEF2C        device tree image (dtb)
> 15506348      0xEC9BAC        device tree image (dtb)
> 15760959      0xF07E3F        LZ4 compressed data, legacy
> 17497877      0x10AFF15       SHA256 hash constants, little endian
> 17821483      0x10FEF2B       mcrypt 2.5 encrypted data, algorithm:
> "]", keysize: 23701 bytes, mode: "(",
> 21542158      0x148B50E       device tree image (dtb)
> 23402211      0x16516E3       LZ4 compressed data, legacy
> 23899460      0x16CAD44       mcrypt 2.5 encrypted data, algorithm:
> ")}", keysize: 11556 bytes, mode: "|",
> 25538245      0x185AEC5       PARity archive data - file number 13345
> 25763629      0x1891F2D       mcrypt 2.5 encrypted data, algorithm:
> "*l", keysize: 20516 bytes, mode: "~",
> 26601909      0x195E9B5       SHA256 hash constants, little endian
> 27027026      0x19C6652       SHA256 hash constants, little endian
> 27294589      0x1A07B7D       ELF, 32-bit LSB processor-specific, ("")
> 27377983      0x1A1C13F       mcrypt 2.5 encrypted data, algorithm:
> "ute0^", keysize: 25971 bytes, mode: """,
> 27653793      0x1A5F6A1       Base64 standard index table
> 28982449      0x1BA3CB1       ELF, 32-bit LSB processor-specific, ("")
> 29102151      0x1BC1047       LZMA compressed data, properties: 0xB7,
> dictionary size: 1572864 bytes, uncompressed size: 106573083904 bytes
> 30170892      0x1CC5F0C       SHA256 hash constants, little endian
> 31079699      0x1DA3D13       lrzip compressed data
> 31079703      0x1DA3D17       LZ4 compressed data
> 31079707      0x1DA3D1B       LZ4 compressed data, legacy
> 31081483      0x1DA440B       EBML file
> 31165137      0x1DB8AD1       lrzip compressed data
> 31165149      0x1DB8ADD       LZ4 compressed data
> 31165156      0x1DB8AE4       LZ4 compressed data, legacy
> 31167662      0x1DB94AE       Gameboy ROM,
> 31168529      0x1DB9811       EBML file
> 31273481      0x1DD3209       lrzip compressed data
> 31273482      0x1DD320A       rzip compressed data - version 32.-20
> (-1785336650 bytes)
> 31552610      0x1E17462       gzip compressed data, from FAT
> filesystem (MS-DOS, OS/2, NT), last modified: 1970-01-01 00:01:36
> (bogus date)
> 32680766      0x1F2AB3E       eCos RTOS string reference: "ECOS field"
> 33863073      0x204B5A1       mcrypt 2.5 encrypted data, algorithm:
> "_fd", keysize: 8881 bytes, mode: "h",
> 34075614      0x207F3DE       ELF, 32-bit LSB processor-specific, ("")
> 34638178      0x2108962       Copyright string: "copyrighted by many
> authors between 1998-2015."
> 34664157      0x210EEDD       SHA256 hash constants, little endian
> 
> Could anyone share insights how to fix it or if there is a workarounds?
> 
> Thanks Ferry.
> 
> Kind regards,
> 
> - jh
> 

Re: zimage Initramfs booting stuck at Start Kernel

[JH]

Hi Ferry,

On 10/29/19, Ferry Toth <fntoth@gmail.com> wrote:
>> How did you build the cpio into the kernel?
>
> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-bsp/conf/machine/edison.conf

Thank you for sharing the config, I added the same thing to my image configure:

INITRAMFS_MAXSIZE ="80000"
INITRAMFS_FSTYPES = "cpio.gz"

But it doesn't seem any changes in zImage-initramfs format, still
stuck in Start Kernel. There is no cpio in zImage-initramfs format
either:

0             0x0             Linux kernel ARM boot executable zImage
(little-endian)
6904          0x1AF8          LZO compressed data
7316          0x1C94          LZO compressed data
7918          0x1EEE          device tree image (dtb)
57505         0xE0A1          device tree image (dtb)
312302        0x4C3EE         LZ4 compressed data, legacy
2049266       0x1F44F2        SHA256 hash constants, little endian
2372864       0x243500        mcrypt 2.5 encrypted data, algorithm:
"]", keysize: 23701 bytes, mode: "(",
6093526       0x5CFAD6        device tree image (dtb)
8127489       0x7C0401        LZ4 compressed data, legacy
8167809       0x7CA181        device tree image (dtb)
8211971       0x7D4E03        device tree image (dtb)
8466697       0x813109        LZ4 compressed data, legacy
10203615      0x9BB1DF        SHA256 hash constants, little endian
10527221      0xA0A1F5        mcrypt 2.5 encrypted data, algorithm:
"]", keysize: 23701 bytes, mode: "(",
14247896      0xD967D8        device tree image (dtb)
16108284      0xF5CAFC        LZ4 compressed data, legacy
16581064      0xFD01C8        mcrypt 2.5 encrypted data, algorithm:
")}", keysize: 11556 bytes, mode: "|",
18187148      0x115838C       PARity archive data - file number 12288
18412397      0x118F36D       mcrypt 2.5 encrypted data, algorithm:
"*l", keysize: 20516 bytes, mode: "~",
18642426      0x11C75FA       mcrypt 2.5 encrypted data, algorithm:
"9n", keysize: 2452 bytes, mode: "4",
19350585      0x1274439       ELF, 32-bit LSB ("")
19742605      0x12D3F8D       ELF, 32-bit LSB ("")
22468397      0x156D72D       ELF, 32-bit LSB processor-specific, ("")
22528640      0x157C280       ELF, 32-bit LSB processor-specific, ("")
22974723      0x15E9103       mcrypt 2.5 encrypted data, algorithm:
">", keysize: 2093 bytes, mode: "-",
23196848      0x161F4B0       ZBOOT firmware header, header size: 32
bytes, load address: 0x0564F721, start address: 0x2E4CEE95, checksum:
0x22771426, version: 0x1D216514, image size: 185068065 bytes
24899585      0x17BF001       LZMA compressed data, properties: 0x63,
dictionary size: 2097152 bytes, uncompressed size: 139006573920 bytes
24899761      0x17BF0B1       LZMA compressed data, properties: 0x6C,
dictionary size: 2097152 bytes, uncompressed size: 541203680 bytes
24899796      0x17BF0D4       LZMA compressed data, properties: 0x63,
dictionary size: 2097152 bytes, uncompressed size: 139810176352 bytes
24940767      0x17C90DF       LZMA compressed data, properties: 0x5E,
dictionary size: 522190848 bytes, uncompressed size: 2157628 bytes
24946105      0x17CA5B9       LZMA compressed data, properties: 0xBE,
dictionary size: -1108672512 bytes, uncompressed size: 138831226112
bytes
24949352      0x17CB268       LZMA compressed data, properties: 0xC0,
dictionary size: -551550976 bytes, uncompressed size: 2117660 bytes
25029743      0x17DEC6F       Copyright string: "Copyright 2017, NXP"
25827134      0x18A173E       Unix path: /var/lib/systemd/
27216461      0x19F4A4D       eCos RTOS string reference: "ECOS field"
27744796      0x1A75A1C       SHA256 hash constants, little endian
27784033      0x1A7F361       mcrypt 2.5 encrypted data, algorithm:
"ute0^", keysize: 25971 bytes, mode: """,
28059592      0x1AC27C8       Base64 standard index table
28258932      0x1AF3274       SHA256 hash constants, little endian
29009250      0x1BAA562       Unix path: /lib/opkg/alternatives/cut
29091303      0x1BBE5E7       LZMA compressed data, properties: 0xB7,
dictionary size: 1572864 bytes, uncompressed size: 106573083904 bytes
31513153      0x1E0DA41       SHA256 hash constants, little endian
31800561      0x1E53CF1       PARity archive data - file number 1944
31937419      0x1E7538B       gzip compressed data, from FAT
filesystem (MS-DOS, OS/2, NT), last modified: 1970-01-01 00:01:36
(bogus date)
32101039      0x1E9D2AF       gzip compressed data, from FAT
filesystem (MS-DOS, OS/2, NT), last modified: 1970-01-01 00:01:36
(bogus date)
32127133      0x1EA389D       gzip compressed data, from FAT
filesystem (MS-DOS, OS/2, NT), last modified: 1970-01-01 00:01:36
(bogus date)
32480356      0x1EF9C64       rzip compressed data - version 16.42
(881272744 bytes)
32537394      0x1F07B32       lrzip compressed data
32537406      0x1F07B3E       LZ4 compressed data
32537413      0x1F07B45       LZ4 compressed data, legacy
32539866      0x1F084DA       Gameboy ROM,
32540730      0x1F0883A       EBML file
32660115      0x1F25A93       LHa 2.x? archive data [lh ] [NSRL|LHA2]
32660163      0x1F25AC3       lrzip compressed data
32660167      0x1F25AC7       LZ4 compressed data
32660171      0x1F25ACB       LZ4 compressed data, legacy
32660179      0x1F25AD3       LZO compressed data
32660287      0x1F25B3F       XAR archive, version: 31320, header
size: 64823, TOC compressed: 6506577760731572164, TOC uncompressed:
18243852667069869871
32660404      0x1F25BB4       Executable script, shebang: "/bin/python3"
32662024      0x1F26208       EBML file
33346732      0x1FCD4AC       Copyright string: "Copyright (C) 2010
Nikolai Kondrashov"
33684559      0x201FC4F       mcrypt 2.5 encrypted data, algorithm:
"_fd", keysize: 8881 bytes, mode: "h",
34425873      0x20D4C11       Copyright string: "copyrighted by many
authors between 1998-2015."
34451850      0x20DB18A       SHA256 hash constants, little endian

What is the Executable script, shebang: "/bin/python3" ? My image does
not have python installed.

Also the eCos RTOS string reference: "ECOS field"? My image does not have ecos??

> And there is the max size!

OK good to know.

>>> And that cpio is ~64MB, so it must be possible.
>>
>> Is the 64MB for compressed cpio.gz? If so, that should be fine. Did
>> you allude that 64MB is also a limitation for cpio?
>
> No I don't think so.

That is good.

Thanks Ferry.

Kind regards,

- jh

Re: zimage Initramfs booting stuck at Start Kernel

[JH]

Hi Ferry,

On 10/29/19, Ferry Toth <fntoth@gmail.com> wrote:
>
> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-bsp/conf/machine/edison.conf
>
> And there is the max size!

Are you able to run u-boot to start kernel in the large size 64 MB?

Thank you.

Kind regards,

- jh

Re: zimage Initramfs booting stuck at Start Kernel

[Ferry Toth]

Op 29-10-2019 om 11:25 schreef JH:
> Hi Ferry,
> 
> On 10/29/19, Ferry Toth <fntoth@gmail.com> wrote:
>>
>> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-bsp/conf/machine/edison.conf
>>
>> And there is the max size!
> 
> Are you able to run u-boot to start kernel in the large size 64 MB?

No, the largest I had was 18MB compressed and it didn't boot. After I 
brought it back to 10MB or so it boots again. Like I said, I don't know 
where the limit comes from.

I think you should be able to make the initramfs minimal and put the 
rest in a separate file system same as I do and your problem will be 
solved. But it looks like if you want to trace the root cause and solve 
it, you are on your own.

> Thank you.
> 
> Kind regards,
> 
> - jh
> 

Re: zimage Initramfs booting stuck at Start Kernel

[JH]

Hi Ferry,

On 10/30/19, Ferry Toth <fntoth@gmail.com> wrote:
> Op 29-10-2019 om 11:25 schreef JH:
>> Hi Ferry,
>>
>> On 10/29/19, Ferry Toth <fntoth@gmail.com> wrote:
>>>
>>> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-bsp/conf/machine/edison.conf
>>>
>>> And there is the max size!
>>
>> Are you able to run u-boot to start kernel in the large size 64 MB?
>
> No, the largest I had was 18MB compressed and it didn't boot. After I
> brought it back to 10MB or so it boots again. Like I said, I don't know
> where the limit comes from.

Oh, so no one could boot zImage-initramfs in a size larger than 10 MB?
And no one concerns?
If anyone could provide more information about kernel.bbclass bundle
function, I would like to help to solve this problem.

> I think you should be able to make the initramfs minimal and put the
> rest in a separate file system same as I do and your problem will be
> solved. But it looks like if you want to trace the root cause and solve
> it, you are on your own.

I have already got zImage-initramfs running in a small size of 8MB
without rootfs bundle.

Thank you.

Kind regards,

- jh