* zimage Initramfs booting stuck at Start Kernel
@ 2019-10-26 9:46 JH
2019-10-26 21:20 ` Ferry Toth
0 siblings, 1 reply; 12+ messages in thread
From: JH @ 2019-10-26 9:46 UTC (permalink / raw)
To: openembedded-core
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-26 9:46 zimage Initramfs booting stuck at Start Kernel JH
@ 2019-10-26 21:20 ` Ferry Toth
2019-10-27 0:27 ` JH
0 siblings, 1 reply; 12+ messages in thread
From: Ferry Toth @ 2019-10-26 21:20 UTC (permalink / raw)
To: openembedded-core
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-26 21:20 ` Ferry Toth
@ 2019-10-27 0:27 ` JH
2019-10-27 12:24 ` Ferry Toth
0 siblings, 1 reply; 12+ messages in thread
From: JH @ 2019-10-27 0:27 UTC (permalink / raw)
To: Ferry Toth; +Cc: openembedded-core
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-27 0:27 ` JH
@ 2019-10-27 12:24 ` Ferry Toth
2019-10-27 21:52 ` JH
0 siblings, 1 reply; 12+ messages in thread
From: Ferry Toth @ 2019-10-27 12:24 UTC (permalink / raw)
To: openembedded-core
Cc: public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-27 12:24 ` Ferry Toth
@ 2019-10-27 21:52 ` JH
2019-10-27 22:27 ` Ferry Toth
0 siblings, 1 reply; 12+ messages in thread
From: JH @ 2019-10-27 21:52 UTC (permalink / raw)
To: Ferry Toth
Cc: public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9,
openembedded-core
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-27 21:52 ` JH
@ 2019-10-27 22:27 ` Ferry Toth
2019-10-28 2:02 ` JH
0 siblings, 1 reply; 12+ messages in thread
From: Ferry Toth @ 2019-10-27 22:27 UTC (permalink / raw)
To: openembedded-core
Cc: public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9,
public-public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9-wOFGN7rlS/M9smdsby/KFg
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-27 22:27 ` Ferry Toth
@ 2019-10-28 2:02 ` JH
2019-10-28 20:46 ` Ferry Toth
0 siblings, 1 reply; 12+ messages in thread
From: JH @ 2019-10-28 2:02 UTC (permalink / raw)
To: Ferry Toth; +Cc: openembedded-core
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-28 2:02 ` JH
@ 2019-10-28 20:46 ` Ferry Toth
2019-10-29 6:27 ` JH
2019-10-29 10:25 ` JH
0 siblings, 2 replies; 12+ messages in thread
From: Ferry Toth @ 2019-10-28 20:46 UTC (permalink / raw)
To: openembedded-core
Cc: public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-28 20:46 ` Ferry Toth
@ 2019-10-29 6:27 ` JH
2019-10-29 10:25 ` JH
1 sibling, 0 replies; 12+ messages in thread
From: JH @ 2019-10-29 6:27 UTC (permalink / raw)
To: Ferry Toth
Cc: public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9,
openembedded-core
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-28 20:46 ` Ferry Toth
2019-10-29 6:27 ` JH
@ 2019-10-29 10:25 ` JH
2019-10-29 17:37 ` Ferry Toth
1 sibling, 1 reply; 12+ messages in thread
From: JH @ 2019-10-29 10:25 UTC (permalink / raw)
To: Ferry Toth
Cc: public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9,
openembedded-core
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-29 10:25 ` JH
@ 2019-10-29 17:37 ` Ferry Toth
2019-10-29 20:42 ` JH
0 siblings, 1 reply; 12+ messages in thread
From: Ferry Toth @ 2019-10-29 17:37 UTC (permalink / raw)
To: openembedded-core
Cc: public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9,
public-public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9-wOFGN7rlS/M9smdsby/KFg
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zimage Initramfs booting stuck at Start Kernel
2019-10-29 17:37 ` Ferry Toth
@ 2019-10-29 20:42 ` JH
0 siblings, 0 replies; 12+ messages in thread
From: JH @ 2019-10-29 20:42 UTC (permalink / raw)
To: Ferry Toth
Cc: public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9,
public-public-openembedded-core-ZwoEplunGu3dfDuKDZ/zN51Ccm5ICvs9-wOFGN7rlS/M9smdsby/KFg,
openembedded-core
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-10-29 20:42 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-26 9:46 zimage Initramfs booting stuck at Start Kernel JH
2019-10-26 21:20 ` Ferry Toth
2019-10-27 0:27 ` JH
2019-10-27 12:24 ` Ferry Toth
2019-10-27 21:52 ` JH
2019-10-27 22:27 ` Ferry Toth
2019-10-28 2:02 ` JH
2019-10-28 20:46 ` Ferry Toth
2019-10-29 6:27 ` JH
2019-10-29 10:25 ` JH
2019-10-29 17:37 ` Ferry Toth
2019-10-29 20:42 ` JH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.