Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
On Fri, 4 Apr 2014, I wrote: On Wed, 2 Apr 2014, Michael Schmitz wrote: 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 chunk size would still be 16 MB, perhaps? Looking at the Penguin source, findRAM() in Source/mmu_support.c sorts the boot info memory mappings so that the largest chunk comes first. In 32-bit mode, it will probably be the only chunk. ... but not always: Designing Cards Drivers 3ed. p.28 says, In the Macintosh IIci and the Macintosh IIsi, physical memory is not in one contiguous block, so the MMU of the 68030 joins the blocks of physical memory to present contiguous logical memory to application software. -- -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
On Thu, 3 Apr 2014, Scott Holder wrote: On 4/1/2014 8:23 AM, Finn Thain wrote: 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. I happen to have my crazy PearPC/Mac OS X-booting LC475 still up and running with a 7.5.5 system folder on it. I rebooted it into 24-bit mode and loading Penguin does give a warning that 32-bit mode works better. Attempting to boot generates: *** Too many memory ranges!!! Error: *** setup_ram_mappings() failure - too many mappings From the Penguin source, MMU/MMU_V2.c, that means more than 32 chunks. I have a 64mb simm in this LC475; I tried popping it out (leaving me with 4mb) and it actually did attempt to unpack the kernel, but there's too little memory to do it. I have a bagful of smaller 72-pin simms kicking around somewhere; I'll have to dig it out of the closet and try it again. You should be able to get Penguin to list the mappings even when it doesn't have room to unpack a kernel. But there's probably no need: it seems highly likely that you'd see no 16 MB chunk on a 16 MB machine in 24-bit mode. Finn -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
On Wed, 2 Apr 2014, Michael Schmitz wrote: Hi Finn, 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 The chunk size would still be 16 MB, perhaps? Looking at the Penguin source, findRAM() in Source/mmu_support.c sorts the boot info memory mappings so that the largest chunk comes first. In 32-bit mode, it will probably be the only chunk. Regardless of 24-bit mode or 32-bit mode, it may not be a 16 MB chunk. Finn -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
On 4/1/2014 8:23 AM, Finn Thain wrote: On Tue, 1 Apr 2014, Geert Uytterhoeven wrote: snip 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. I happen to have my crazy PearPC/Mac OS X-booting LC475 still up and running with a 7.5.5 system folder on it. I rebooted it into 24-bit mode and loading Penguin does give a warning that 32-bit mode works better. Attempting to boot generates: *** Too many memory ranges!!! Error: *** setup_ram_mappings() failure - too many mappings I have a 64mb simm in this LC475; I tried popping it out (leaving me with 4mb) and it actually did attempt to unpack the kernel, but there's too little memory to do it. I have a bagful of smaller 72-pin simms kicking around somewhere; I'll have to dig it out of the closet and try it again. Sadly my IIci is still misbehaving due to bad caps. I do have a working 840AV here... I believe it should work in 24-bit mode. I don't have any older 32-bit unclean Macs of the era when 24-bit was normal to try with to see if maybe the memory controller works better. 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. All I can say here is I ran 2.0-era kernels on a Quadra 840AV which does have interleaved RAM way back in the day just fine. I haven't yet gotten modern kernels (even the setup that works on the LC475) booting on it yet; sadly I'm not much good for coding or debug tracing. Scott -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Hi Michael,
On Mon, Mar 31, 2014 at 11:24 PM, Michael Schmitz schmitz...@gmail.com 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 ...
get_bi_record BI_MEMCHUNK will return a pointer to the first mem_info
struct.
If the first chunk is at least 8 MiB it should be not that intrusive.
If it isn't, and you have to use multiple chunks, it becomes more complicated.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Hi Geert, 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). And the chunk the kernel runs from would always be the first chunk listed in bootinfo, since that's the one mapped at virtual address zero? Don't know about Mac, but I have some memories of interleaved banks and such... Not sure I've ever seen accelerators or memory upgrades on the Macs that I hacked on. 4 MB was sort of plenty in those days. Cheers, Michael -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Hi Michael,
On Tue, Apr 1, 2014 at 9:39 AM, schmitz
schm...@biophys.uni-duesseldorf.de wrote:
On Mon, Mar 31, 2014 at 11:24 PM, Michael Schmitz schmitz...@gmail.com
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 ...
get_bi_record BI_MEMCHUNK will return a pointer to the first mem_info
struct.
Yep, that's as far as I got - if I read bootinfo.h right, this will need to
have an offset of 12 bytes added to get to the size member, correct?
Nope, only 4. A0 points to the bootinfo record payload, which is of
type struct mem_info * in this case:
movew %a0@(BIR_SIZE),%d0
lea %a0@(BIR_DATA),%a0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Hi Michael,
On Tue, Apr 1, 2014 at 9:45 AM, schmitz
schm...@biophys.uni-duesseldorf.de 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).
And the chunk the kernel runs from would always be the first chunk listed in
bootinfo, since that's the one mapped at virtual address zero?
The kernel always runs in the first chunk.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Hi Geert, Hi Michael, On Tue, Apr 1, 2014 at 9:39 AM, schmitz schm...@biophys.uni-duesseldorf.de wrote: On Mon, Mar 31, 2014 at 11:24 PM, Michael Schmitz schmitz...@gmail.com 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 ... get_bi_record BI_MEMCHUNK will return a pointer to the first mem_info struct. Yep, that's as far as I got - if I read bootinfo.h right, this will need to have an offset of 12 bytes added to get to the size member, correct? Nope, only 4. A0 points to the bootinfo record payload, which is of type struct mem_info * in this case: Right - should have read on to find the get_bi_record defs. While poking around in head.S, I came across a comment that stated the second page at the start of the kernel is used for the kernel page dir - that is the second page of virtual address space (FastRAM, in the case we care about here), not physcial address space, right? Still wondering why the kernel in FastRAM won't reboot cleanly... Cheers, Michael -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Hi Michael,
On Tue, Apr 1, 2014 at 10:12 AM, schmitz
schm...@biophys.uni-duesseldorf.de wrote:
While poking around in head.S, I came across a comment that stated the
second page at the start of the kernel is used for the kernel page dir -
that is the second page of virtual address space (FastRAM, in the case we
care about here), not physcial address space, right?
The kernel is loaded in the second page of RAM. Initially, this page just
contains a few branches and the bootinfo versions. The code jumps to
_start, and the second page is reused for the kernel page dir:
ENTRY(_stext)
bras1f /* Jump over bootinfo version numbers */
.long BOOTINFOV_MAGIC
.long MACH_AMIGA, AMIGA_BOOTI_VERSION
1: jra __start
.equkernel_pg_dir,_stext
.equ.,_stext+PAGESIZE
ENTRY(_start)
jra __start
__INIT
ENTRY(__start)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
schmitz schm...@biophys.uni-duesseldorf.de writes: What size FastRAM did precipitate that bug for you, Andreas? It's the combination of kernel size and FastRAM setting that matters. You can easily watch it by adding the bootmem_debug kernel parameter. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
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 0x - 0x : 0x00C0 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 0x1000 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 0xc0 Bootstrap logical 1: 0x Bootstrap physical : 0x Dump of bootinfo, version 2.0: BI_MACHTYPE = 0x3 BI_CPUTYPE= 0x2 BI_FPUTYPE= 0x2 BI_MMUTYPE= 0x2 BI_MEMCHUNK[0].addr = 0x BI_MEMCHUNK[0].size = 0x00c0 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 = 0x6004 BI_MAC_VDEPTH = 0x4 BI_MAC_VROW = 0x140 BI_MAC_VDIM = 0x01900280 BI_MAC_VLOGICAL = 0x6004 BI_MAC_SCCBASE= 0x50f04000 BI_MAC_BTIME = 0x83da53fb BI_MAC_GMTBIAS= 0x0 BI_MAC_MEMSIZE= 0xc BI_MAC_CPUID = 0x1 BI_MAC_ROMBASE= 0x4080 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 -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Hi Finn, 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 The chunk size would still be 16 MB, perhaps? (Unless Geert is right and interleaving means multiple small memory chunks. I doubt Apple engineers would have gone that far.) Cheers, Michael -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Hi Michael,
On Sun, Mar 30, 2014 at 1:01 AM, Michael Schmitz schmitz...@gmail.com wrote:
see the following patch series for the hopefully final word on
the 'make ST-RAM pool accessible for kernels running from FastRAM'
story.
When submitting a take three, please annotate the individual patches
with [PATCH v3 x/y].
It would also have been nice to CC the block resp. SCSI maintainers to
get their acks for patches 3 and 4, but I'm gonna take them through the
m68k tree anyway.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Andreas, 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 ... Cheers, Michael On Tue, Apr 1, 2014 at 9:58 AM, Andreas Schwab sch...@linux-m68k.org wrote: Michael Schmitz schmitz...@gmail.com writes: see attached. I may have disabled nfcon entirely - usually I use parallel debug with ARAnyM. Thanks, with debug=par early printk is working. So the problem is that kernel-in-FastRAM does not solve the kernel-too-big/FastRAM-too-big problem, since the page tables for the first node (== FastRAM) memory must still fit in INIT_MAPPED_SIZE (== 4Mb) - kernel-size. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Don't top post! Michael Schmitz schmitz...@gmail.com writes: 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. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Atari kernel-in-FastRAM patches, take three
Michael Schmitz schmitz...@gmail.com writes: see the following patch series for the hopefully final word on the 'make ST-RAM pool accessible for kernels running from FastRAM' story. Would you mind sharing your config? I'm always getting a panic very early, even before nfcon is ready, which makes it almost impossible to debug. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
