On Tue, 23 Mar 2021, Brad Boyer wrote:
> On Tue, Mar 23, 2021 at 06:50:05PM +1100, Finn Thain wrote:
> > Anyway, surely this test for CPU_68020 in Source/mmu_support.c in
> > Penguin is bogus. This must have to do with some quirk of the Mac II
> > logic board and not the type of MMU or CPU.
> >
On Tue, 23 Mar 2021, Michael Schmitz wrote:
> On 22/03/21 6:24 pm, Finn Thain wrote:
> > > I guess once the RAM chunk list has been sorted, it was most
> > > convenient to use that sorted list directly for the bootinfo
> > > records.
> > >
> > A constraint that says the first chunk must be the
On Tue, Mar 23, 2021 at 10:48:07AM +1300, Michael Schmitz wrote:
> As you said, there is no distinction made between 020 and 030 in that code,
> so the same hack should have been applied to 030. Maybe the MacII (were
> there other 020 Macs?) was the only one with RAM banks A and B spaced closer
> t
On Tue, Mar 23, 2021 at 06:50:05PM +1100, Finn Thain wrote:
> Anyway, surely this test for CPU_68020 in Source/mmu_support.c in Penguin
> is bogus. This must have to do with some quirk of the Mac II logic board
> and not the type of MMU or CPU.
>
> So, why sort chunks by address on Mac II? Beats
Hi Michael,
On Mon, Mar 22, 2021 at 10:48 PM Michael Schmitz wrote:
> Based on the commit that Geert cited, I'd be inclined to sort chunks by
> physical address, find the lowest chunk having size >= 16 MB and put that
> one and the higher ones into bootinfo. (Or failing that, find the one
> havin
On Mon, 22 Mar 2021, Geert Uytterhoeven wrote:
> >
> > I know the head.S MMU code was completely rewritten around that time
> > to accommodate changes needed for the Mac port. What we used before on
> > Atari and Amiga bears little to no relation to what we have now. My
> > guess is that 030 (h
Hi Finn,
On 22/03/21 6:24 pm, Finn Thain wrote:
I guess once the RAM chunk list has been sorted, it was most convenient
to use that sorted list directly for the bootinfo records.
A constraint that says the first chunk must be the largest one is
undesirable because if the largest chunk has high
Hi Michael,
On Mon, Mar 22, 2021 at 2:19 AM Michael Schmitz wrote:
> On 21/03/21 2:31 pm, Finn Thain wrote:
> > This "hack" first appeared in Penguin-14. The file Penguin.doc says,
> >
> >Status: Changed 980301
> >
> >New setting - "68020: Don't force kernel into bank A".
> >Normally
On Mon, 22 Mar 2021, Michael Schmitz wrote:
> On 21/03/21 2:31 pm, Finn Thain wrote:
> >
> > > If Penguin then loads the kernel in that same chunk, there really is
> > > no other choice? (The kernel expects the memory chunk it runs from
> > > to be listed first in the bootinfo struct).
> > >
>
On Mon, Mar 22, 2021 at 02:19:10PM +1300, Michael Schmitz wrote:
> Does any of this help with the problem of RBV Macs? Video RAM must start at
> address 0x0, and reordering RAM to have the largest chunk at that address
> would occupy the RBV video range and render RBV unusable? Can you even
> rearr
Hi Finn,
On 21/03/21 2:31 pm, Finn Thain wrote:
If Penguin then loads the kernel in that same chunk, there really is no
other choice? (The kernel expects the memory chunk it runs from to be
listed first in the bootinfo struct).
But finding the largest chunk and putting it first doesn't imply
Hi Finn,
On Sun, Mar 21, 2021 at 2:31 AM Finn Thain wrote:
> On Sat, 20 Mar 2021, Michael Schmitz wrote:
> > Am 19.03.21 um 12:49 schrieb Finn Thain:
> > > AIUI, Penguin needs a large physically contiguous region, so it used
> > > the largest pysical RAM chunk (which was bank B). But that alone
>
On Sat, 20 Mar 2021, Michael Schmitz wrote:
> Hi Finn,
>
> Am 19.03.21 um 12:49 schrieb Finn Thain:
> > 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.
>
>
Hi Finn,
Am 19.03.21 um 12:49 schrieb Finn Thain:
> 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.
If Penguin then loads the kernel in that same chunk, there r
Le 19/03/2021 à 00:49, Finn Thain a écrit :
>
> 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 0x1000") and the kernel then goes and drops t
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 0x1000") and the kernel then goes and drops that segment
> (i.e. Linux says "Ignoring memory chu
On Tue, 16 Mar 2021, Stan Johnson wrote:
>
> This is getting complicated quickly, and some of my earlier conclusions
> were wrong.
>
Yes, it's getting complicated. But it should not be necessary to rearrange
RAM or video cards to avoid a crash from v5.11...
I suspect that v5.10 (with CONFIG_
On 3/16/21 1:04 AM, Finn Thain wrote:
> On Mon, 15 Mar 2021, Stan Johnson wrote:
>
>>
>> The issue appears not to be limited to built-in video. With 16 MiB in
>> Bank A (4 x 4 MiB), 64 MiB in Bank B (4 x 16 MiB), a RasterOps
>> ColorBoard 264 in the Nubus slot nearest the PDS slot (which contain
On Tue, Mar 16, 2021 at 05:56:02PM +1100, Finn Thain wrote:
> I didn't know that the IIsi limited video RAM to 1 MB. It's unsurprising
> though, considering the drawbacks of RAM based video.
It really doesn't have anything to do with the video. It's just that
the first bank is soldered on instead
On Mon, 15 Mar 2021, Stan Johnson wrote:
>
> The issue appears not to be limited to built-in video. With 16 MiB in
> Bank A (4 x 4 MiB), 64 MiB in Bank B (4 x 16 MiB), a RasterOps
> ColorBoard 264 in the Nubus slot nearest the PDS slot (which contains a
> 32K cache card), and a Farallon Ethern
On Sun, 14 Mar 2021, Brad Boyer wrote:
> Perhaps we could find some other use for the rest of the RAM in that
> bank (a IIsi has a fixed 1MB there, but it was possible to put a lot
> more than that in bank A on a IIci).
>
I didn't know that the IIsi limited video RAM to 1 MB. It's unsurprising
On Mär 15 2021, Geert Uytterhoeven wrote:
> Two of the main differences between m68k platforms and the ia32 PC
> platform are that (a) physical RAM doesn't always start at address
> zero,
That is shared with a lot of platforms.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerpr
Hi Andreas,
On Mon, Mar 15, 2021 at 9:57 AM Andreas Schwab wrote:
> On Mär 15 2021, Geert Uytterhoeven wrote:
> > Two of the main differences between m68k platforms and the ia32 PC
> > platform are that (a) physical RAM doesn't always start at address
> > zero,
>
> That is shared with a lot of pl
Hi Brad,
On Fri, Mar 12, 2021 at 2:46 AM Brad Boyer wrote:
> On Thu, Mar 11, 2021 at 11:39:41AM -0700, Stan Johnson wrote:
> > When booting modern kernels (4.x or 5.x) on a Mac IIci, the kernel sees
> > only half of installed memory if the built-in video is used. Using a
> > Nubus video card, al
On Mon, Mar 15, 2021 at 02:33:26PM +1300, Michael Schmitz wrote:
> On 15/03/21 10:13 am, Brad Boyer wrote:
> >I believe one of the headaches is that the address is non-programmable
> >and requires the framebuffer not just to be in bank A, but to start at
> >address 0 which means we can't put the ke
Hi Brad,
On 15/03/21 10:13 am, Brad Boyer wrote:
On Mon, Mar 15, 2021 at 08:28:37AM +1300, Michael Schmitz wrote:
I'm pretty sure this has never worked. Though there ought to be a way to
make use of RAM in bank 0 for video as long as the kernel is loaded at
address 0 in that bank. Or if that's
On Mon, Mar 15, 2021 at 08:28:37AM +1300, Michael Schmitz wrote:
> I'm pretty sure this has never worked. Though there ought to be a way to
> make use of RAM in bank 0 for video as long as the kernel is loaded at
> address 0 in that bank. Or if that's not possible, use the same trick as I
> do on A
Hi Brad,
On 12/03/21 2:18 pm, Brad Boyer wrote:
On Thu, Mar 11, 2021 at 11:39:41AM -0700, Stan Johnson wrote:
When booting modern kernels (4.x or 5.x) on a Mac IIci, the kernel sees
only half of installed memory if the built-in video is used. Using a
Nubus video card, all of the installed memo
On Thu, Mar 11, 2021 at 11:39:41AM -0700, Stan Johnson wrote:
> When booting modern kernels (4.x or 5.x) on a Mac IIci, the kernel sees
> only half of installed memory if the built-in video is used. Using a
> Nubus video card, all of the installed memory is seen. This may be a
> Penguin issue, th
29 matches
Mail list logo
