Problem with packages version(on m68k architecture, but also on amd64 and maybe
somewhere else)
linux-headers-2.6-* and linux-image-2.6-* and linux-doc-2.6-* for m68k have
dummy package in which version doesn't relate with official repository of
debian builds.
Like linux-headers-2.6-amiga (3.0.0
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,
On Mon, Mar 31, 2014 at 10:12 PM, Geert Uytterhoeven
wrote:
> Hi Michael,
>
> On Mon, Mar 31, 2014 at 10:06 AM, Michael Schmitz
> wrote:
>> The new atari_stram_alloc interface returns kernel virtual addresses
>> even if the kernel runs in FastRAM. These addresses are not
>> guarantee
On 03/31/2014 01:46 AM, Geert Uytterhoeven wrote:
Hi Jens,
If you don't object, I'd like to take this one through the m68k tree, as it
depends on a new m68k platform function.
Sure, that's fine.
--
Jens Axboe
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of
Hi Michael,
On Mon, Mar 31, 2014 at 10:06 AM, Michael Schmitz wrote:
> The new atari_stram_alloc interface returns kernel virtual addresses
> even if the kernel runs in FastRAM. These addresses are not
> guaranteed to be identical with the physical addresses. Since ST-RAM
> mappings have not been
The new atari_stram_alloc interface returns kernel virtual addresses
even if the kernel runs in FastRAM. These addresses are not
guaranteed to be identical with the physical addresses. Since ST-RAM
mappings have not been set up by mem_init, virt_to_phys() and its
cousin do not work and the atari_st
With the kernel running from FastRAM instead of ST-RAM, none of ST-RAM is
mapped by mem_init, and DMA-addressable buffer must be mapped by ioremap.
Use platform specific virt/phys translation helpers for this case.
Signed-off-by: Michael Schmitz
Cc: linux-s...@vger.kernel.org
---
drivers/scsi/a
Hi Geert,
changes to stram.c and atafb.c patches as requested. The external_addr
case is still untested - may have other bugs that I've not seen when
changing the external_addr types.
CC to the relevant lists for floppy and SCSI patches.
Cheers,
Michael
--
To UNSUBSCRIBE, email to d
With the kernel running from FastRAM instead of ST-RAM, none of ST-RAM is
mapped by mem_init, and DMA-addressable buffer must be mapped by ioremap.
Use platform specific virt/phys translation helpers for this case.
Signed-off-by: Michael Schmitz
Cc: linux-ker...@vger.kernel.org
---
drivers/bloc
With the kernel loaded to FastRAM (TT-RAM), none of the ST-RAM
address range is mapped by init_mem, and ST-RAM is not accessible
through the normal allocation pathways as a result.
Implement ST-RAM pool allocation to be based on physical addresses
always (it already was when the kernel was loaded
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 James,
If you don't object, I'd like to take this one through the m68k tree, as it
depends on a new m68k platform function.
On Sun, Mar 30, 2014 at 1:01 AM, Michael Schmitz wrote:
> With new ST-RAM allocation to work also when the kernel is running
> from FastRAM, use dedicated virt/phys tran
Hi Jens,
If you don't object, I'd like to take this one through the m68k tree, as it
depends on a new m68k platform function.
On Sun, Mar 30, 2014 at 1:01 AM, Michael Schmitz wrote:
> With new ST-RAM allocation to work also when the kernel is running
> from FastRAM, use dedicated virt/phys trans
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
17 matches
Mail list logo
