[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Booting Kernel on Amiga 3000

Hi Geert,

Am 09.09.2022 um 19:34 schrieb Geert Uytterhoeven:

Hi Michael,

On Fri, Sep 9, 2022 at 7:03 AM Michael Schmitz <schmitzmic@gmail.com> wrote:

Am 09.09.2022 um 13:36 schrieb Finn Thain:


Kernel 5.19, intrd 5.19




[    0.000000] Linux version 5.19.0-1-m68k (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 Debian 5.19.6-1 (2022-09-01)
[    0.000000] printk: console [debug0] enabled
[    0.000000] Amiga hardware found: [A3000] VIDEO BLITTER AMBER_FF AUDIO FLOPPY A3000_SCSI KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA DENISE_HR AGNUS_HR_PAL MAGIC_REKICK ZORRO3
[    0.000000] initrd: 0f7f6794 - 10000000


Length is 0x80986d.


...

Kernel 5.18, intrid 5.18




[    0.000000] Linux version 5.18.0-3-m68k (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-4) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 Debian 5.18.14-1 (2022-07-23)
[    0.000000] printk: console [debug0] enabled
[    0.000000] Amiga hardware found: [A3000] VIDEO BLITTER AMBER_FF AUDIO FLOPPY A3000_SCSI KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA DENISE_HR AGNUS_HR_PAL MAGIC_REKICK ZORRO3
[    0.000000] initrd: 0f7f7b16 - 10000000


Length is 0x8084eb.

...

kernel 5.19, intrid 5.15




[    0.000000] Linux version 5.19.0-1-m68k (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 Debian 5.19.6-1 (2022-09-01)
[    0.000000] printk: console [debug0] enabled
[    0.000000] Amiga hardware found: [A3000] VIDEO BLITTER AMBER_FF AUDIO FLOPPY A3000_SCSI KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA DENISE_HR AGNUS_HR_PAL MAGIC_REKICK ZORRO3
[    0.000000] initrd: 0f83283d - 10000000


Length is 0x7cd7c4 which is below 8 MiB. Moreover, this is a known-good
initrd. So the oops appears to be caused by a kernel change and not initrd
growth.


All these have the initrd in the second memory chunk - at least one of
the successful boots had the initrd in the first (8 MB) chunk).
Just spotted another difference - in the success case, the initrd log message is printed after the initmem setup log message.
Maybe add initcall_debug to the kernel options so we see what happens in which order in succes and fault cases? 



I know nothing about the way amiboot works, and how the RAM chunk to
copy the initrd image to is selected. Just speculating: maybe amiboot
plus initrd size must be below 8 MB for the first chunk to get used?


m68kboot/common/amiga/linuxboot.c

    bi.ramdisk.addr = (u_long)start_mem+mem_size-rd_size;
That's after figuring out which RAM segment the kernel will get loaded to. If I understand you right, that is always the first memory block. In all cases, this is the 0x8000000 one (hence the message about chunk 0x7800000 getting ignored by mem setup).
But the initrd does not always get loaded at the end of the kernel RAM segment - in fact, in all cases where it's instead loaded to the later ignored segment, the kernel boots fine. 



However, that's not where it is loaded initially:

    memreq = kernel_size+bi_size+rd_size;
    memptr = (char *)AllocMem(memreq, MEMF_FAST | MEMF_PUBLIC | MEMF_CLEAR);

I expect the allocated memory to be from the largest (second)
block of memory.

Later, everything is copied to the first memory block.
But from a quick glance, I see no check to verify the first
block is sufficiently large.

I think we really need to see the output of "amiboot -d",
for both the good and the bad cases.


But that's a little academic. I really wonder what makes the initrd at
the end of the second RAM chunk fault. But e.g. the range

0f83283d - 10000000

extends one byte beyond what's mapped

node   0: [mem 0x0000000008000000-0x000000000fffffff]


That's because the first printed range is initrd_start, initrd_end,
while the second is (u64)start_pfn << PAGE_SHIFT,
((u64)end_pfn << PAGE_SHIFT) - 1).
And in the success case, initrd_end does just serendipitously happen to be mapped (first byte of the kernel RAM segment), while in the problem case it doesn't (beyond end of kernel RAM segment).
How is initrd_end calculate? It's just initrd_start + initrd_size, which is just fine because the calculation of the bootconfig address from initrd_end is correct, and initrd_end should never be accessed. 


and the fault occurs at faddr=0ffffff4, at which point the processor
probably pre-fetched out to 10000000.


Or perhaps memcmp() (that's __builtin_memcmp()?) loads 4 words
at once?
It's lib/string.c:memcmp() for me. That does load (unsigned long) for as long as there's still more than sizeof(unsigned long), then compares bytes. 

Might depend on the GCC version?
Changing amiboot to leave some space before the end of RAM is probably quite hard, but moving the loaded initrd down by a few bytes early on in the boot (in setup_arch()??) might be a simple way to test the hypothesis. 

Cheers,

	Michael



Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Reply to: