Re: Kernel versions 6.x don't boot on Amiga 4000

[Michael Schmitz <schmitzmic@gmail.com>]

Eero,

that issue (kernel running from TT-RAM) was fixed quite a few years ago 
(but maybe not in 2013), in the sense that ST-RAM could be used for 
drivers (SCSI, atafb). Using ST-RAM as normal VM should have been made a 
lot easier by changing to memblock, but AFAIR there are still some bits 
missing.

RAM must be listed in bootinfo with the chunk holding the kernel first, 
_not_ in ascending address order, so that second option is expected to 
crash.

This isn't related to the current issue for all I can see.

Cheers,

	Michael

Am 27.02.2023 um 22:41 schrieb Eero Tamminen:
> Hi,
>
> On 27.2.2023 9.19, Michael Schmitz wrote:
>> Am 27.02.2023 um 18:55 schrieb Finn Thain:
>>> On Mon, 27 Feb 2023, Michael Schmitz wrote:
>>>
>>>>>
>>>>> Bisected to commit 376e3fdecb0dcae2 ("m68k: Enable memtest
>>>>> functionality") in v5.17-rc1.  Reverting that on top of latest fixes
>>>>> the issue.
>>>>
>>>> Yes, I'm sorry to say that was the only likely candidate. Can't see why
>>>> though - are Macs all configured to have RAM start at address zero, and
>>>> possibly contiguous, Finn?
>>>>
>>>
>>> I don't really understand your question. This was not a Mac patch. The
>>> issue seems to be about the locations initrd_start and initrd_end in
>>> relation to the various memory segments (?)
>>
>> I didn't realize that - thanks for pointing this out.
>>
>>> This seems to be the same bug that was raised about 6 months ago... I
>>> had
>>> thought it was a bootloader bug but I'm out of my depth here.
>>>
>>> https://lists.debian.org/debian-68k/2022/09/msg00047.html
>>> https://lists.debian.org/debian-68k/2022/09/msg00051.html
>>> https://lists.debian.org/debian-68k/2022/09/msg00055.html
>>
>> I had forgotten all about that one... Thanks for jogging my memory!
>>
>> In this case though, the bug happens when the ramdisk is loaded in the
>> lowest address memory chunk, at least at a lower address than the one
>> the kernel runs from.
>
> I'm wondering whether this old Atari side boot issue is related at all...
>
> When adding Linux bootinfo support to Hatari emulator (from Aranym
> emulator) few years ago, I noticed that:
> "Linux barfs at ST-RAM memory range given after TT-RAM.  However, if
> kernel is loaded to TT-RAM and ST-RAM range is given before TT-RAM
> range, kernel crashes."
>
> => Only working config was Linux being loaded to ST-RAM, TT-RAM being
> given only after that in bootinfo, and initrd ramdisk after kernel.
>
> Based on mails in archive, this seemed to have been a known Linux/Atari
> issue already in 2013.
>
>
>> The crashes in the above thread were all from boots where the initrd
>> got loaded at the end of the memory chunk the kernel runs from.
>>
>> Time to try using copy_from_kernel_nofault() to copy the ramdisk into
>> its final location? (just kidding)
>
>
>     - Eero
>
> PS. For people familiar only with Amiga terminology, ST-RAM = chip RAM,
> TT-RAM = fast RAM.