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 Pen
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, fi
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
On 4/1/2014 8:23 AM, Finn Thain wrote:
On Tue, 1 Apr 2014, Geert Uytterhoeven wrote:
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 me
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
c
Hi Finn,
On Tue, Apr 1, 2014 at 2:23 PM, Finn Thain wrote:
>> 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 meant that if you have e.g. 16 MiB of RAM, b
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 tha
schmitz 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 = 5
Hi Geert,
Hi Michael,
On Tue, Apr 1, 2014 at 9:39 AM, schmitz
wrote:
On Mon, Mar 31, 2014 at 11:24 PM, 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 ther
Hi Michael,
On Tue, Apr 1, 2014 at 10:12 AM, schmitz
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
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
Hi Geert
Hi Michael,
On Mon, Mar 31, 2014 at 11:24 PM, 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 ...
"get_
Hi Michael,
On Tue, Apr 1, 2014 at 9:45 AM, 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 yo
Hi Michael,
On Tue, Apr 1, 2014 at 9:39 AM, schmitz
wrote:
>> On Mon, Mar 31, 2014 at 11:24 PM, 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 mo
Hi Michael,
On Tue, Apr 1, 2014 at 1:52 AM, Michael Schmitz
wrote:
>> Michael Schmitz 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
Hi Michael,
On Mon, Mar 31, 2014 at 11:24 PM, 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 ...
"get_bi_record BI_ME
Andreas,
> Don't top post!
Sorry - gurgle made me do it :')
>
> Michael Schmitz 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 me
Don't top post!
Michael Schmitz 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
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 wrote:
> Michael Sc
Michael Schmitz 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
Hi Geert,
Hi Michael,
On Sun, Mar 30, 2014 at 1:01 AM, Michael Schmitz 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
Hi Michael,
On Sun, Mar 30, 2014 at 1:01 AM, Michael Schmitz 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 v
Andreas,
see attached. I may have disabled nfcon entirely - usually I use
parallel debug with ARAnyM.
Cheers,
Michael
On Mon, Mar 31, 2014 at 11:34 AM, Andreas Schwab wrote:
> Michael Schmitz writes:
>
>> see the following patch series for the hopefully final word on
>> the 'make ST-RAM p
Michael Schmitz 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, whic
Geert,
see the following patch series for the hopefully final word on
the 'make ST-RAM pool accessible for kernels running from FastRAM'
story.
ST-RAM pool is allocated from an arch initcall if the kernel runs
in FastRAM, at which time memory mapping support is up and runnin
25 matches
Mail list logo
