On Tue, Oct 17, 2023 at 02:46:20PM +0300, Andy Shevchenko wrote:
> On Tue, Oct 17, 2023 at 01:32:53PM +0300, Andy Shevchenko wrote:
> > On Tue, Oct 17, 2023 at 01:29:27PM +0300, Andy Shevchenko wrote:
> > > On Tue, Oct 17, 2023 at 01:27:19PM +0300, Andy Shevchenko wrote:
> > > > On Wed, Aug 30, 2023 at 12:24:34PM +0200, Jan Kara wrote:
...
> > > > This merge commit (?) broke boot on Intel Merrifield.
> > > > It has earlycon enabled and only what I got is watchdog
> > > > trigger without a bit of information printed out.
>
> Okay, seems false positive as with different configuration it
> boots. It might be related to the size of the kernel itself.
So, here is the thing, I dug into it and found a workaround.
TL;DR: It all was started from the commit [0].
But read the long read below for all the details.
The memory layout of the platform in question is that
BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000400-0x0000000000097fff] usable
BIOS-e820: [mem 0x0000000000100000-0x0000000003ffffff] usable
BIOS-e820: [mem 0x0000000004000000-0x0000000005ffffff] reserved
BIOS-e820: [mem 0x0000000006000000-0x000000003f4fffff] usable
BIOS-e820: [mem 0x000000003f500000-0x000000003fffffff] reserved
BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
BIOS-e820: [mem 0x00000000fec04000-0x00000000fec07fff] reserved
BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
So, as you can see the first 64Mb (excluding the first one) is usable memory.
It's immediately followed up by reserved one.
Back in 2014-2016 the kernel and initramfs have been smaller and basically
the window of 64Mb was enough to load kernel at the 0x100000 (1Mb) and
followed by initramfs somewhere at the offset 0x3000000 (48Mb). But after
the mentioned commit [0] people have noticed that it failed to boot [1]
and workaround was quickly found back then by moving initramfs to the next
available window, i.e. 0x6000000 (96Mb), problem solved! No, not really.
With the kernel growing bigger and bigger it started randomly fail to boot
as I have reported here. Mostly I'm using this platform with kexec'ing new
kernels and I was under the impression that kexec is more flexible than
U-Boot that's used on this platform. It appears that kexec'ed boots also
started failing!
So, what the commit [0] does is that it starts occupying the end of the given
window and hence it was put a garbage to the initramfs. On top of that it appears
that kexec doesn't properly calculating the window size which is needed for the
kernel to be unpacked. See patches [2][3] that I upstreamed to the kexec v2.0.30.
In internal discussion with HPA it appears that many bootloaders didn't get it
right due to... documentation unclearness. This what I have fixed in kernel
recently [4]. Took me a while to go through the assembler code and figure all
this out.
TODO in the kernel (as I referred in some discussion that kernel can do better):
Ideally we should split kaslr algorithm for memory search for even non-KASLR
kernels and make use of it at the very beginning, so for relocatable kernels
we may find better addresses and still trust bootloader that puts kernel and
initramfs binaries close to each other in the same memory window.
[0]: 974f221c84b0 ("x86/boot: Move compressed kernel to the end of the decompression buffer")
[1]: https://lore.kernel.org/all/20160816040147.GA4492@xxxxxxxxxxxxxxxx/
[2]: https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=ec3e4dfeec22a2c78d6c7fbccf006bf4a7ba635d
[3]: https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=07a6217af3cfb7b7952be22a58d4a3a365e422bb
[4]: be4ca6c53e66 ("x86/Documentation: Update algo in init_size description of boot protocol")
--
With Best Regards,
Andy Shevchenko
