Re: Kernel 5.10-rc4 doesn't boot
>
>
> On 11/25/20 5:52 AM, Elimar Riesebieter wrote:
>>
>> * John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>[2020-11-25
>> 13:04 +0100]:
>>>
>>> On 11/25/20 12:40 PM, Elimar Riesebieter wrote:
>>>>
>>>> I tried to boot linux-image-5.10.0-rc4-powerpc on my PowerBook5,8.
>>>> It seems the ramdisk isn't loaded as ist stocks at the white
>>>> firmware boot. A custom build fails as well. I have no idea how to
>>>> debug that. I am booting via yaboot.
>>>
>>> FWIW, if you think the initrd isn't being loaded, you may have run
>>> into a limitation with Yaboot. You have to keep in mind that Yaboot
>>> isn't being actively maintained anymore, at least not as it used to
>>> be. So in case of an incompatible change on the kernel side, you may
>>> run into such problems with the bootloader. You could try switching
>>> to GRUB.
>>
>> What is the preferred way to switch to grub2? Elimar
>
>
> HelloElimar,
>
> I can confirm that Linux 5.10.0-rc5 also does not work on a PowerBook
> Lombard, hanging at the "found display ... opening ..." screen after
> loading the initrd.img file.
>
> The 5.10.0-rc5 initrd.img can be used with an older 5.8.4 kernel;
> however, the 5.8.4 initrd.img does not work with the 5.10.0-rc5
> kernel, so the problem appears to be with the 5.10.0-rc5 kernel.
>
> ...
>
> -Stan Johnson
>
The Wallstreet also won't boot any 5.10.0-rc* kernel (it hangs at the
BootX screen). The last v5.9 mainline kernel (v5.9.11) boots on both
the Wallstreet and Lombard (so it's likely the same problem).
I saw during one of the boots that PPC 601 support has been removed; I
thought that there was still an effort not to do that (but that's a
separate issue).
A git bisect going from v5.9 to v5.10.0-rc1 resulted in the following,
after about 13 kernels:
-----
69a1593abdbcf03a76367320d929a8ae7a5e3d71 is the first bad commit
commit 69a1593abdbcf03a76367320d929a8ae7a5e3d71
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date: Thu Oct 1 15:35:38 2020 +0000
powerpc/32s: Setup the early hash table at all time.
At the time being, an early hash table is set up when
CONFIG_KASAN is selected.
There is nothing wrong with setting such an early hash table
all the time, even if it is not used. This is a statically
allocated 256 kB table which lies in the init data section.
This makes the code simpler and may in the future allow to
setup early IO mappings with fixmap instead of hard coding BATs.
Put create_hpte() and flush_hash_pages() in the .ref.text section
in order to avoid warning for the reference to early_hash[]. This
reference is removed by MMU_init_hw_patch() before init memory is
freed.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link:
https://lore.kernel.org/r/b8f8101c368b8a6451844a58d7bd7d83c14cf2aa.1601566529.git.christophe.leroy@csgroup.eu
:040000 040000 20b02d14bb334fc81d7a5f431f1565b7616c59d2
f3a39013f94c482c566f0d208f9104a4c6e0538f M arch
-----
I'm cc'ing Christophe Leroy, since I don't know what to do next.
-Stan Johnson
Reply to: