All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de>,
	Andreas Schwab <schwab@linux-m68k.org>,
	Michael Schmitz <schmitzmic@gmail.com>,
	Linux/m68k <linux-m68k@vger.kernel.org>,
	debian m68k <debian-68k@lists.debian.org>
Subject: Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Date: Tue, 1 Apr 2014 23:23:00 +1100 (EST)	[thread overview]
Message-ID: <alpine.LNX.2.00.1404012153360.16187@nippy.intranet> (raw)
In-Reply-To: <CAMuHMdUeMv1R69vSLv0HZpKEgVpRUG_iMs=61JWVubBsSN7VVA@mail.gmail.com>


On Tue, 1 Apr 2014, Geert Uytterhoeven wrote:

> On Tue, Apr 1, 2014 at 1:52 AM, Michael Schmitz wrote:
> > > > do we know the size of the first memory chunk early enough in 
> > > > head.S? Maybe it's time to increase INIT_MAPPED_SIZE at least in 
> > > > cases where we know that there's more than 4 MB in the first 
> > > > memchunk ...
> > >
> > > How do you know?  You would have to reimplement the check 
> > > paging_init does.
> >
> > I see - as a heuristic, we can probably assume that the first memchunk 
> > is the relevant one, and especially in the case of FastRAM, also the 
> > larger one. Does this hold for Amiga/Mac/VME as well?
> 
> People want to run the kernel in the fastest memory chunk, which is 
> typically also the largest (slow Amiga mainboard memory may be 2 - 16 
> MiB for Linux-capable machines, accelerator memory may be larger).
> 
> Don't know about Mac,

It may be possible to boot Linux with MacOS running in 24-bit mode, and 
ISTR that this leads to a large number of memory chunks. The Penguin 
documentation says use 32-bit mode (which means installing Mode32 if you 
have old MacOS and old ROMs). The only Mac I have here is running MacOS 
7.6 so I can't test 24-bit mode. You can see the debug output from Penguin 
below.

> but I have some memories of interleaved banks and such...

There are some Mac models with memory controllers that do interleaving. I 
don't know whether interleaving is relevant here. I'd have to consult the 
Penguin source code to know whether it behaves differently on different 
models.

Perhaps you're thinking of this --

    "68020: Don't force kernel into bank A: [optional] This is a special 
    option for the 68020 and MacII owners only. It has to do with the 
    physical arrangement of the memory banks in the MacII ... NOTE: This 
    option has been removed from Penguin 18."

from http://www.mac.linux-m68k.org/docs/penguin.php

-- 


Logging started Friday, 1 January 1904 12:19:07 AM
Penguin App version 19

Logical To Physical Mapping table (V2)
Logical -> physical : length
0x00000000 -> 0x00000000 : 0x00C00000

System: 7.6.1
Gestalt ID: 33 (PowerBook 180)
CPU: 68030
FPU: 68882
Physical RAM: 12 MB
Command line is 'consoleblank=0 console=tty console=ttyS0 earlyprintk'
GUnzipping Macintosh HD:Desktop Folder:vmlinux.gz
.Kernel format: ELF

The kernel will be located at physical 0x00001000
Kernel at logical address 0x5d4008
GUnzipping Macintosh HD:Desktop Folder:vmlinux.gz
..............................................Read 2794880 bytes for segment 0, requested 2794880
.Read 101752 bytes for segment 1, requested 101752

Bootstrap's bootinfo version: 2.0
Kernel's bootinfo version	: 2.0
Kernel entry physical is 0x2000
RAM disk at 0x008b7008, ends at 0x00929008, size is 456 K
Kernel segment 0 at 0x5d4008, size 2917724
Kernel segment 1 at 0x89d008, size 102400
Kernel size is 0x2e2000

boot_info is at 0x8b6008
boot_info size is dynamic

ramdisk logical target 0xb8e000
ramdisk physical at 0xb8e000
ramdisk physical top at 0xc00000

Bootstrap logical 1: 0x00000000
Bootstrap physical : 0x00000000

Dump of bootinfo, version 2.0:
BI_MACHTYPE           = 0x3
BI_CPUTYPE            = 0x2
BI_FPUTYPE            = 0x2
BI_MMUTYPE            = 0x2
BI_MEMCHUNK[0].addr   = 0x00000000
BI_MEMCHUNK[0].size   = 0x00c00000
BI_RAMDISK.addr       = 0x00b8e000
BI_RAMDISK.size       = 0x00072000
BI_COMMAND_LINE       = consoleblank=0 console=tty console=ttyS0 earlyprintk
BI_MAC_MODEL          = 0x21
BI_MAC_VADDR          = 0x60040000
BI_MAC_VDEPTH         = 0x4
BI_MAC_VROW           = 0x140
BI_MAC_VDIM           = 0x01900280
BI_MAC_VLOGICAL       = 0x60040000
BI_MAC_SCCBASE        = 0x50f04000
BI_MAC_BTIME          = 0x83da53fb
BI_MAC_GMTBIAS        = 0x0
BI_MAC_MEMSIZE        = 0xc
BI_MAC_CPUID          = 0x1
BI_MAC_ROMBASE        = 0x40800000

Booting Linux (fasten seat belts, please)...
Waking up serial ports, no rest for the wicked...
Modem port awake and configured!
slot_int_set: slot 0x00, drvr_refnum -49, spID 0xBC, spExtDev 0x00, ON 0

Logging ended Friday, 1 January 1904 12:19:50 AM

  parent reply	other threads:[~2014-04-01 12:23 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-30  0:01 [PATCH 0/4] Atari kernel-in-FastRAM patches, take three Michael Schmitz
2014-03-30  0:01 ` [PATCH 1/4] m68k/atari - stram: alloc ST-RAM pool even if kernel not in ST-RAM Michael Schmitz
2014-03-30 19:11   ` Geert Uytterhoeven
2014-03-31  1:58     ` Michael Schmitz
2014-03-30  0:01 ` [PATCH 2/4] m68k/atari - atafb: convert allocation of fb ram to new interface Michael Schmitz
2014-03-30 19:11   ` Geert Uytterhoeven
2014-03-30  0:01 ` [PATCH 3/4] m68k/atari - ataflop: use correct virt/phys translation for DMA buffer Michael Schmitz
2014-03-31  7:46   ` Geert Uytterhoeven
2014-03-31 14:28     ` Jens Axboe
2014-03-30  0:01 ` [PATCH 4/4] m68k/atari - atari_scsi: " Michael Schmitz
2014-03-31  7:48   ` Geert Uytterhoeven
2014-03-30 22:34 ` [PATCH 0/4] Atari kernel-in-FastRAM patches, take three Andreas Schwab
2014-03-31  1:55   ` Michael Schmitz
2014-03-31 20:58     ` Andreas Schwab
2014-03-31 21:24       ` Michael Schmitz
2014-03-31 22:39         ` Andreas Schwab
2014-03-31 23:52           ` Michael Schmitz
2014-04-01  7:28             ` Geert Uytterhoeven
2014-04-01  7:45               ` schmitz
2014-04-01  7:50                 ` Geert Uytterhoeven
2014-04-01 12:23               ` Finn Thain [this message]
2014-04-01 12:41                 ` Geert Uytterhoeven
2014-04-01 18:56                 ` Michael Schmitz
2014-04-04  6:12                   ` Finn Thain
2014-04-09  6:44                     ` Finn Thain
2014-04-04  3:43                 ` Scott Holder
2014-04-04  6:08                   ` Finn Thain
2014-04-01  7:24         ` Geert Uytterhoeven
2014-04-01  7:39           ` schmitz
2014-04-01  7:49             ` Geert Uytterhoeven
2014-04-01  8:12               ` schmitz
2014-04-01  8:23                 ` Geert Uytterhoeven
2014-04-01  9:06             ` Andreas Schwab
2014-03-31  7:42 ` Geert Uytterhoeven
2014-03-31  7:54   ` Michael Schmitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.00.1404012153360.16187@nippy.intranet \
    --to=fthain@telegraphics.com.au \
    --cc=debian-68k@lists.debian.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=schmitz@mail.biophys.uni-duesseldorf.de \
    --cc=schmitzmic@gmail.com \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.