On Thu, 18 Mar 2021, Finn Thain wrote:
> Am I right in thinking that Linux only crashes when Penguin loads the > kernel into Bank A (i.e. Penguin says "The kernel will be located at > physical 0x00001000") and the kernel then goes and drops that segment > (i.e. Linux says "Ignoring memory chunk at 0x0:0x1000000 before the > first chunk")? After re-reading your message, I think I got that wrong -- you said that "Penguin-1.txt is with 80 MB (crashes)". So I don't have a good explanation for the v5.11 crash. > > Thanks for collecting these logs. The Penguin logs show that rbv_boot is > false, indicating that the on-board video is not in use, as described. > > So I think the important question is, why does Penguin fail to sort the > segments in this case? That is, why did Penguin produce this list: > > Physical RAM: 80 MB > ... > BI_MEMCHUNK[0].addr = 0x04000000 > BI_MEMCHUNK[0].size = 0x04000000 > BI_MEMCHUNK[1].addr = 0x00000000 > BI_MEMCHUNK[1].size = 0x01000000 > > rather than a sorted list, something like the other example: > > Physical RAM: 32 MB > ... > BI_MEMCHUNK[0].addr = 0x00000000 > BI_MEMCHUNK[0].size = 0x01000000 > BI_MEMCHUNK[1].addr = 0x04000000 > BI_MEMCHUNK[1].size = 0x01000000 > After looking at the Penguin source code, I understand how this happens. Penguin sorts the pysical memory chunks by size, not by address, except on 68020, where it sorts by address. If you move the 64 MB to bank A and the 16 MB to bank B, does that solve the problem? (Please also try v5.10 before you make that change.) AIUI, Penguin needs a large physically contiguous region, so it used the largest pysical RAM chunk (which was bank B). But that alone doesn't really justify the weird sort order. Laurent, can you comment on this? In particular, does EMILE sort memory chunks the way Penguin does?
