Re: Improving Performance
Hi Geert,
Hi Michael,
On Tue, Mar 25, 2014 at 8:53 AM, schmitz
schm...@biophys.uni-duesseldorf.de wrote:
How can I delay the call to atari_stram_reserve_pages() until after VM init,
but before driver initcalls?
arch_initcall()?
subsys_initcall()?
Right - I'll try and see what works. Could only think of
device_initcall() which might have been too late.
Or you can delay the ioremap() until the first caller of atari_stram_alloc()?
Messy.
If the kernel runs in ST-RAM, I think you have to keep the reservation in
early code, to avoid no ST-RAM being available later.
Yep, that was the reason it was called from early setup. Still a bit
messy but can't be helped for now.
Thanks,
Michael
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5333cb38.9090...@biophys.uni-duesseldorf.de
Re: Improving Performance
Hi Geert, The problem is - it dies when calling ioremap: stram_virt_offset = ioremap(stram_pool.start, resource_size(stram_pool) - stram_pool.start); Why do you subtract stram_pool.start from the size again? Good question - no idea where that got left over from. Answer: misplaced bracket. Your suggestion for using ioremap had one bracket missing, and I picked the wrong place to add it :-( Using ioremap in an arch_initcall() context does work - with that, atafb can be simplified to set the right cache mode unconditionally again. Only tested in ARAnyM so far, so this will need testing on real hardware again after cleaning up the patches a bit more. Should get to that over the weekend. With a view towards supporting hardware that does not rely on ST-RAM for frame buffer memory, we may need a virt/phys translation that works on both ioremapped and kmalloced memory. Has this been done before? Cheers, Michael -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5333dd87.8010...@biophys.uni-duesseldorf.de
Re: Improving Performance
Hi Geert,
Hi Michael,
On Sat, Mar 15, 2014 at 7:29 PM, schmitz
schm...@biophys.uni-duesseldorf.de wrote:
The problem is - it dies when calling ioremap:
stram_virt_offset = ioremap(stram_pool.start,
resource_size(stram_pool) - stram_pool.start);
Why do you subtract stram_pool.start from the size again?
Good question - no idea where that got left over from.
Regarding your other comment that ioremap may be called too early into
the boot - you're right, the kernel dies before it reports any VM stats.
The full log up to that point is:
Linux version 3.14.0-rc6-atari-164151-g0939d5c (schmitz@xplor) (gcc
version 4.6.3 (GCC) ) #209 Mon Mar 17 21:13:51 NZDT 2014
Saving 174 bytes of bootinfo
console [debug0] enabled
Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K
SCC_DMA SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
Ignoring memory chunk at 0x0:0xe0 before the first chunk
Fix your bootloader or use a memfile to make use of this area!
On node 0 totalpages: 130688
free_area_init_node: node 0, pgdat 002b95d8, node_mem_map 0037c000
DMA zone: 1149 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 130688 pages, LIFO batch:31
atari_stram pool: kernel not in ST-RAM, using ioremap!
atari_stram pool: size = 1048576 bytes, resource = [???
0x1000-0x00100fff flags 0x0]
atari_stram pool: start = 1000, end = 00100fff
Unable to handle kernel NULL pointer dereference at virtual address (null)
Oops:
Modules linked in:
PC: [000896a4] kmem_cache_alloc+0x10/0x9a
SR: 2700 SP: 0029ded0 a2: 002a42d8
d0: 80d0d1: 0013d2: 80d0d3: 0007ff90
d4: 0001d5: 00d0a0: 0029c000a1: 002a762e
Process swapper (pid: 0, task=002a42d8)
Frame format=4 fault addr= fslw=01050200
Stack from 0029df0c:
0010 0008 0021705a 002db308 0007ff90 80d0
0010
0001 1000 0021705a 00080bbe 0010 0001
0001
2000 d000 00d0 6bb4 6bb4 0010 0001
0001
0008 0021705a 002b9070 000b3ef4 0021705a 002db308 002d55e8
0029dfc8
002d626e 1000 0010 0001 002b907c 002d4844 012f9fd0
002eb0ae
003bee10 01001000 0021705a
0029dff8
How can I delay the call to atari_stram_reserve_pages() until after VM
init, but before driver initcalls?
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/533135ec.6040...@biophys.uni-duesseldorf.de
Re: Improving Performance
Hi Michael,
On Tue, Mar 25, 2014 at 8:53 AM, schmitz
schm...@biophys.uni-duesseldorf.de wrote:
How can I delay the call to atari_stram_reserve_pages() until after VM init,
but before driver initcalls?
arch_initcall()?
subsys_initcall()?
Or you can delay the ioremap() until the first caller of atari_stram_alloc()?
If the kernel runs in ST-RAM, I think you have to keep the reservation in
early code, to avoid no ST-RAM being available later.
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAMuHMdUxuPdZ_VwmMvF-6X2LwO=krk_AskpZfiB+4zQf6TWG=a...@mail.gmail.com
Re: Improving Performance
Hi Michael,
On Sat, Mar 15, 2014 at 7:29 PM, schmitz
schm...@biophys.uni-duesseldorf.de wrote:
The problem is - it dies when calling ioremap:
stram_virt_offset = ioremap(stram_pool.start,
resource_size(stram_pool) - stram_pool.start);
Why do you subtract stram_pool.start from the size again?
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAMuHMdUcuZAN6zZZjUsXSpFze768fA9AcQ6T0UOig-my=fb...@mail.gmail.com
Re: Improving Performance
Hi Andreas,
schmitz schm...@biophys.uni-duesseldorf.de writes:
Andreas,
works, but doesn't quite do what I need - to emulate the behaviour of
ataboot, the ST-RAM chunk needs to be added after the FastRAM one, not
omitted.
Does that work?
Should work - did you change anything else than swapping the meminfo
chunk order? I'd tried that in the meantime and I do get the kernel to
boot up to the point where atafb is initialized, On my Falcon, it just
hangs there. Aranym reports a double bus fault, and quits.
Some oblique virt==phys assumptions in atafb, or early startup mappings
did not survive past mem init (unlikely).
I'll try your new patch on a vanila aranym source next, to make sure I
didn't botch anything.
Thanks,
Michael
Andreas.
diff --git c/src/bootos_linux.cpp w/src/bootos_linux.cpp
index 78adbb8..8bd25ad 100644
--- c/src/bootos_linux.cpp
+++ w/src/bootos_linux.cpp
@@ -409,9 +409,10 @@ int LinuxBootOs::checkKernel(void)
Elf32_Ehdr *kexec_elf; /* header of kernel executable */
Elf32_Phdr *kernel_phdrs;
unsigned long min_addr=0x, max_addr=0;
- unsigned long kernel_size, mem_ptr;
+ unsigned long kernel_size, mem_ptr, kernel_offset;
int i;
const char *kname, *kernel_name=vmlinux;
+ bool load_to_fastram = bx_options.lilo.load_to_fastram FastRAMSize
0;
kexec_elf = (Elf32_Ehdr *) kernel;
if (memcmp( kexec_elf-e_ident[EI_MAG0], ELFMAG, SELFMAG ) == 0) {
@@ -475,6 +476,10 @@ int LinuxBootOs::checkKernel(void)
kernel_size = max_addr - min_addr;
D(bug(lilo: kernel_size=%lu,kernel_size));
+ if (load_to_fastram)
+ kernel_offset = FastRAMBase;
+ else
+ kernel_offset = 0;
mem_ptr = KERNEL_START;
for (i=0; iSDL_SwapBE16(kexec_elf-e_phnum); i++) {
unsigned long segment_length;
@@ -490,21 +495,29 @@ int LinuxBootOs::checkKernel(void)
}
segment_ptr = SDL_SwapBE32(kernel_phdrs[i].p_vaddr)-PAGE_SIZE;
- memcpy(((char *)RAMBaseHost) + mem_ptr + segment_ptr, ((char *) kexec_elf) + segment_offset, segment_length);
+ if (load_to_fastram)
+ memcpy(FastRAMBaseHost + mem_ptr + segment_ptr, (char
*) kexec_elf + segment_offset, segment_length);
+ else
+ memcpy(RAMBaseHost + mem_ptr + segment_ptr, (char *)
kexec_elf + segment_offset, segment_length);
- D(bug(lilo: Copied segment %d: 0x%08x,0x%08x at 0x%08x,i,segment_offset,segment_length,mem_ptr+segment_ptr));
+ D(bug(lilo: Copied segment %d: 0x%08x,0x%08x at
0x%08x,i,segment_offset,segment_length,kernel_offset+mem_ptr+segment_ptr));
}
/*--- Copy the ramdisk after kernel (and reserved bootinfo) ---*/
if (ramdisk ramdisk_length) {
unsigned long rd_start;
unsigned long rd_len;
+ unsigned long rd_offset;
+ if (load_to_fastram)
+ rd_offset = KERNEL_START + kernel_size + MAX_BI_SIZE;
+ else
+ rd_offset = 0;
rd_len = ramdisk_length - RAMDISK_FS_START;
- if (FastRAMSizerd_len) {
+ if (FastRAMSize rd_offset + rd_len) {
/* Load in FastRAM */
- rd_start = FastRAMBase;
- memcpy(FastRAMBaseHost, ((unsigned char *)ramdisk) +
RAMDISK_FS_START, rd_len);
+ rd_start = FastRAMBase + rd_offset;
+ memcpy(FastRAMBaseHost + rd_offset, (unsigned char
*)ramdisk + RAMDISK_FS_START, rd_len);
} else {
/* Load in ST-RAM */
rd_start = RAMSize - rd_len;
@@ -519,7 +532,7 @@ int LinuxBootOs::checkKernel(void)
for (i=0; i16; i++) {
uint32 *tmp;
- tmp = (uint32 *)(((unsigned char *)FastRAMBaseHost) /*+ rd_start*/ + 512);
+ tmp = (uint32 *)((unsigned char *)FastRAMBaseHost +
rd_offset + 512);
D(bug(lilo: ramdisk[%d]=0x%08x,i,
SDL_SwapBE32(tmp[i])));
}
#endif
@@ -557,10 +570,14 @@ int LinuxBootOs::checkKernel(void)
bi.mch_type = SDL_SwapBE32(ATARI_MACH_AB40);
bi.num_memory=0;
- ADD_CHUNK(0, RAMSize);
+ /* If loading to FastRAM switch the order of ST and Fast RAM */
+ if (!load_to_fastram)
+ ADD_CHUNK(0, RAMSize);
if (FastRAMSize0) {
ADD_CHUNK(FastRAMBase, FastRAMSize);
}
+ if (load_to_fastram)
+ ADD_CHUNK(0, RAMSize);
bi.num_memory=SDL_SwapBE32(bi.num_memory);
if (!create_bootinfo()) {
@@ -569,24 +586,30 @@ int LinuxBootOs::checkKernel(void)
}
/*--- Copy boot info in RAM ---*/
- memcpy(RAMBaseHost + KERNEL_START + kernel_size, bi_union.record,
bi_size);
-D(bug(lilo: bootinfo at 0x%08x,KERNEL_START +
Re: Improving Performance
Stefan, In that case, it might be sufficient to change the fixed Videl base address to a variable one in the atafb driver, and perhaps use kmalloc instead of stram_alloc to allocate the frame buffer. If someone with access to this hardware is interested in giving this a try, I'd be happy to elaborate. Yeah, i'd be happy to try. Regarding the ideas about support for kernel in ST-RAM with framebuffer support that Geert and I bounced around - see my two patches to the lists a few minutes ago. With Andreas' ARAnyM patch, this can all be tested without hardware. Allocation of framebuffer memory from ST-RAM does work, but atafb init causes a double bus fault at present. Not certain why that is - missing mapping, or some bug in atafb that does only manifest when virtual and physical addresses are different. Cheers, Michael -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/532949cd.9070...@biophys.uni-duesseldorf.de
Re: Improving Performance
schmitz schm...@biophys.uni-duesseldorf.de writes: Should work - did you change anything else than swapping the meminfo chunk order? Only renaming [LILO]SkipSTRAM to [LILO]LoadToFastRAM. 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, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mvmha6usivl@hawking.suse.de
Re: Improving Performance
Am 18.03.2014 um 01:59 schrieb schmitz schm...@biophys.uni-duesseldorf.de: Stefan - Geert's ioremap trick does not absolve us from having ST-RAM mapped in the first place. This is shaping up more complex than I thought. Would it work when SPARSEMEM would be available on m68k? I thought that's what it's all about: making different kind of memory available to the system and being able to load the kernel where you want have it to run from. -- Ciao...// Fon: 0381-2744150 Ingo \X/ http://blog.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/31bb4a85-b524-473f-b7c7-5d26df38a...@2014.bluespice.org
Re: Improving Performance
Ingo, Am 18.03.2014 um 01:59 schrieb schmitz schm...@biophys.uni-duesseldorf.de: Stefan - Geert's ioremap trick does not absolve us from having ST-RAM mapped in the first place. This is shaping up more complex than I thought. Would it work when SPARSEMEM would be available on m68k? I thought that's what it's all about: making different kind of memory available to the system and being able to load the kernel where you want have it to run from. sparsemem support would solve many of our problems. I haven't heard anyone volunteer to write sparsemem support for m68k, though. Cheers, Michael -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5327f0b3.3090...@biophys.uni-duesseldorf.de
Re: Improving Performance
Andreas,
works, but doesn't quite do what I need - to emulate the behaviour of
ataboot, the ST-RAM chunk needs to be added after the FastRAM one, not
omitted.
I'll play a bit with your patch, should be easy to modify unless I'm
missing something.
Stefan - Geert's ioremap trick does not absolve us from having ST-RAM
mapped in the first place. This is shaping up more complex than I thought.
Cheers,
Michael
Michael Schmitz schm...@biophys.uni-duesseldorf.de writes:
I haven't found a way to tell ARAnyM to load the kernel to FastRAM, so
this will need testing on real hardware,
Can you try this patch? Use [LILO] SkipSTRAM = true to enable.
Andreas.
diff --git a/src/bootos_linux.cpp b/src/bootos_linux.cpp
index 78adbb8..c0e55bb 100644
--- a/src/bootos_linux.cpp
+++ b/src/bootos_linux.cpp
@@ -409,7 +409,7 @@ int LinuxBootOs::checkKernel(void)
Elf32_Ehdr *kexec_elf; /* header of kernel executable */
Elf32_Phdr *kernel_phdrs;
unsigned long min_addr=0x, max_addr=0;
- unsigned long kernel_size, mem_ptr;
+ unsigned long kernel_size, mem_ptr, kernel_offset;
int i;
const char *kname, *kernel_name=vmlinux;
@@ -475,6 +475,10 @@ int LinuxBootOs::checkKernel(void)
kernel_size = max_addr - min_addr;
D(bug(lilo: kernel_size=%lu,kernel_size));
+ if (bx_options.lilo.skip_stram)
+ kernel_offset = FastRAMBase;
+ else
+ kernel_offset = 0;
mem_ptr = KERNEL_START;
for (i=0; iSDL_SwapBE16(kexec_elf-e_phnum); i++) {
unsigned long segment_length;
@@ -490,21 +494,29 @@ int LinuxBootOs::checkKernel(void)
}
segment_ptr = SDL_SwapBE32(kernel_phdrs[i].p_vaddr)-PAGE_SIZE;
- memcpy(((char *)RAMBaseHost) + mem_ptr + segment_ptr, ((char *) kexec_elf) + segment_offset, segment_length);
+ if (bx_options.lilo.skip_stram)
+ memcpy (FastRAMBaseHost + mem_ptr + segment_ptr, (char
*) kexec_elf + segment_offset, segment_length);
+ else
+ memcpy(RAMBaseHost + mem_ptr + segment_ptr, (char *)
kexec_elf + segment_offset, segment_length);
- D(bug(lilo: Copied segment %d: 0x%08x,0x%08x at 0x%08x,i,segment_offset,segment_length,mem_ptr+segment_ptr));
+ D(bug(lilo: Copied segment %d: 0x%08x,0x%08x at
0x%08x,i,segment_offset,segment_length,kernel_offset+mem_ptr+segment_ptr));
}
/*--- Copy the ramdisk after kernel (and reserved bootinfo) ---*/
if (ramdisk ramdisk_length) {
unsigned long rd_start;
unsigned long rd_len;
+ unsigned long rd_offset;
+ if (bx_options.lilo.skip_stram)
+ rd_offset = KERNEL_START + kernel_size + MAX_BI_SIZE;
+ else
+ rd_offset = 0;
rd_len = ramdisk_length - RAMDISK_FS_START;
- if (FastRAMSizerd_len) {
+ if (FastRAMSize rd_offset + rd_len) {
/* Load in FastRAM */
- rd_start = FastRAMBase;
- memcpy(FastRAMBaseHost, ((unsigned char *)ramdisk) +
RAMDISK_FS_START, rd_len);
+ rd_start = FastRAMBase + rd_offset;
+ memcpy(FastRAMBaseHost + rd_offset, (unsigned char
*)ramdisk + RAMDISK_FS_START, rd_len);
} else {
/* Load in ST-RAM */
rd_start = RAMSize - rd_len;
@@ -519,7 +531,7 @@ int LinuxBootOs::checkKernel(void)
for (i=0; i16; i++) {
uint32 *tmp;
- tmp = (uint32 *)(((unsigned char *)FastRAMBaseHost) /*+ rd_start*/ + 512);
+ tmp = (uint32 *)((unsigned char *)FastRAMBaseHost +
rd_offset + 512);
D(bug(lilo: ramdisk[%d]=0x%08x,i,
SDL_SwapBE32(tmp[i])));
}
#endif
@@ -557,7 +569,8 @@ int LinuxBootOs::checkKernel(void)
bi.mch_type = SDL_SwapBE32(ATARI_MACH_AB40);
bi.num_memory=0;
- ADD_CHUNK(0, RAMSize);
+ if (!bx_options.lilo.skip_stram)
+ ADD_CHUNK(0, RAMSize);
if (FastRAMSize0) {
ADD_CHUNK(FastRAMBase, FastRAMSize);
}
@@ -569,24 +582,30 @@ int LinuxBootOs::checkKernel(void)
}
/*--- Copy boot info in RAM ---*/
- memcpy(RAMBaseHost + KERNEL_START + kernel_size, bi_union.record,
bi_size);
-D(bug(lilo: bootinfo at 0x%08x,KERNEL_START + kernel_size));
+ if (bx_options.lilo.skip_stram)
+ memcpy(FastRAMBaseHost + KERNEL_START + kernel_size,
bi_union.record, bi_size);
+ else
+ memcpy(RAMBaseHost + KERNEL_START + kernel_size,
bi_union.record, bi_size);
+ D(bug(lilo: bootinfo at 0x%08x, kernel_offset + KERNEL_START +
kernel_size));
for (i=0; i16; i++) {
uint32 *tmp;
- tmp = (uint32 *)(((unsigned char *)RAMBaseHost) + KERNEL_START +
Re: Improving Performance
Hi Michael,
git clone git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
Fails with:
schmitz@hobbes:~/kexec-tools$ make
gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include
-I./util_lib/include -Iinclude/ -I./kexec/arch/m68k/include -c -MD -o
kexec/kexec.o kexec/kexec.c
In file included from kexec/kexec.c:44:
kexec/kexec-syscall.h:52:2: #error Unknown processor architecture. Needs a
kexec_load syscall number.
In file included from kexec/kexec.c:44:
Strange.
kexec/kexec-syscall.h: In function `kexec_load':
kexec/kexec-syscall.h:61: error: `__NR_kexec_load' undeclared (first use in
this function)
kexec/kexec-syscall.h:61: error: (Each undeclared identifier is reported
only once
kexec/kexec-syscall.h:61: error: for each function it appears in.)
make: *** [kexec/kexec.o] Error 1
(no syscall no. defined in the kernel headers).
Hmm, I probably used a unistd.h that did have the syscall number defined,
cfr. below.
In file included from kexec/arch/m68k/kexec-m68k.c:19:
kexec/arch/m68k/bootinfo.h:12: error: syntax error before __be16
Missing typedefs for __u16, __u32, __be16 and __be32 (the former two being
present in /usr/include/asm/types.h but not picked up from there). Patch
attached as well - may be harmful on more recent m68k installations.
I did intend this to be used with recent kernel headers, as created by
make headers_install for v3.14-rc1 and later.
That was BTW my main motivation to clean up asm/bootinfo.h: before
v3.14-rc1, make headers_install would install asm/bootinfo.h at
all, so you had to rely on the very old version from glibc-headers.
I'll look in the preprocessor issue later.
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/camuhmdxcoto3rlb+opro8zh--g-pw7xn6dsduxwkf+3mw+s...@mail.gmail.com
Re: Improving Performance
Geert, Does the hack below (not even compile-tested) work? It maps pool_size (default 1 MiB) of ST-RAM and makes the pool use that. Sort of - boots with kernel in ST-RAM, but nothing shown on the screen. SCSI appears to allocate DMA-able memory though: Turns out the test for kernel in ST-RAM is faulty. I'll have to find a better test, atafb_init: start atafb_init: initializing Falcon hw atafb: screen_base 007f4000 real_screen_base 007f4000 screen_len 69632 Determined 640x400, depth 1 virtual 640x870 Console: switching to mono frame buffer device 80x25 fb0: frame buffer device, using 68K of video memory That's just the same behaviour as before, when the kernel was loaded to FastRAM. Cheers, Michael -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5324928d.6040...@biophys.uni-duesseldorf.de
Re: Improving Performance
Geert, Does the hack below (not even compile-tested) work? It maps pool_size (default 1 MiB) of ST-RAM and makes the pool use that. Sort of - boots with kernel in ST-RAM, but nothing shown on the screen. SCSI appears to allocate DMA-able memory though: Turns out the test for kernel in ST-RAM is faulty. I'll have to find a better test, Checking for the first memory chunk address to be located at 0x0 works (the bootloader will place the chunk with the kernel loaded in to first). The problem is - it dies when calling ioremap: stram_virt_offset = ioremap(stram_pool.start, resource_size(stram_pool) - stram_pool.start); I guess the FastRAM chunk is mapped at virtual address 0, and ST-RAM is unmapped? Cheers, Michael atafb_init: start atafb_init: initializing Falcon hw atafb: screen_base 007f4000 real_screen_base 007f4000 screen_len 69632 Determined 640x400, depth 1 virtual 640x870 Console: switching to mono frame buffer device 80x25 fb0: frame buffer device, using 68K of video memory That's just the same behaviour as before, when the kernel was loaded to FastRAM. Cheers, Michael -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53249c01.3000...@biophys.uni-duesseldorf.de
Re: Improving Performance
Geert, git clone git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git cd kexec-tools ./bootstrap ./configure make install It has less build requirements than ARAnyM ;-) Missing typedefs for __u16, __u32, __be16 and __be32 (the former two being present in /usr/include/asm/types.h but not picked up from there). Patch attached as well - may be harmful on more recent m68k installations. Untested, yet. Works - now what's the proper way to invoke kexec to boot into the loaded kernel? kexec -e will reboot right away with no shufdown. Does kexec (no arguments) perform a regular shutdown? Will this use the machine reset vector to boot, or just run kexec -e instead of halting? Cheers, Michael -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/77f8c9c6b9ee1ca900232c7bfd53e...@biophys.uni-duesseldorf.de
Re: Improving Performance
Geert,
Sort of - boots with kernel in ST-RAM, but nothing shown on the
screen. SCSI
appears to allocate DMA-able memory though:
Ignoring memory chunk at 0x0:0xe0 before the first chunk
Haha, you still have it in the bootinfo. Fortunately Linux doesn't use
it ;-)
No idea how to suppress it - that would need changes to the bootstrap.
More debugging of atafb needed - I have a hunch that the ioremapped
kernel
virtual address is being used as physical address for atafb.
Indeed, atafb needs the physical address, so the ioremap() should be
moved
from atari_stram_init() to atafb.
That'll complicate matters (kernel in ST-RAM vs. not), see further
below.
There may be other virt/phys bugs in atafb, as before virt == phys for
ST-RAM,
so conversion didn't matter.
screen_info.screen_base should be the virtual address,
fb_fix_info.smem_start should be the physical address.
OK, I'll go through atafb to check - I remember it uses screen_base and
real_screen_base so we might just need to set them up right.
For comparison, amiga_chip_alloc() always returns virtual addresses.
Conversion is done through ZTWO_VADDR()/ZTWO_PADDR(), which is
just an offset, as we always map the first 16 MiB using transparent
translation.
That's set up in head,S, and not unmapped later, right?
Ah, perhaps you can do something similar? Hence keep the ioremap() in
atari_stram_init(), and provide helpers atari_stram_to_virt() and
atari_stram_to_phys() for phys/virt conversion?
The helpers can be no-ops if ST-RAM is not ioremapped().
That way the drivers don't need to know.
We'll have to do it that way - there's no generic virt_to_phys for
ioremapped memory AFAIR.
One other thing: for bookkeeping, it would be better if the pool is
registered
using the physical addresses, as its resources will show up in
/proc/iomem.
Hence:
stram_pool.start = PAGE_SIZE;
stram_pool.end = stram_pool.start + pool_size - 1;
stram_virt_offset = ioremap(stram_pool.start,
resource_len(stram_pool) - stram_pool.start;
and
void *atari_stram_to_virt(unsigned long phys)
{
return (void *)(phys + stram_virt_offset);
}
That should work. I'll look at that as time permits.
(if the kernel is in ST-RAM, stram_virt_offset should be 0);
and call atari_stram_to_virt() just before returning from
atari_stram_alloc().
Same for the virt to phys conversion in atari_stram_free().
Need to batten down the hatches now - we expect cyclone Lusi to hit
from
tomorrow.
Keep Lusi out. The only cyclones that belong near a hacker's house are
Altera
Cyclones ;-)
These don't come in 130 k gust units, I hope ... Less rain, more wind
seems to be the theme for overnight and tomorrow.
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/6ad3513fe2e5f3edf576e7a25e535...@biophys.uni-duesseldorf.de
Re: Improving Performance
Geert, Hi Michael, On Thu, Mar 13, 2014 at 7:35 AM, schmitz schm...@biophys.uni-duesseldorf.de wrote: (Neither do I have kexec tools yet - nice plug though, Geert! I definitely need to play with kexec.) git clone git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git cd kexec-tools ./bootstrap ./configure make install It has less build requirements than ARAnyM ;-) Fails with: schmitz@hobbes:~/kexec-tools$ make gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include -I./util_lib/include -Iinclude/ -I./kexec/arch/m68k/include -c -MD -o kexec/kexec.o kexec/kexec.c In file included from kexec/kexec.c:44: kexec/kexec-syscall.h:52:2: #error Unknown processor architecture. Needs a kexec_load syscall number. In file included from kexec/kexec.c:44: kexec/kexec-syscall.h: In function `kexec_load': kexec/kexec-syscall.h:61: error: `__NR_kexec_load' undeclared (first use in this function) kexec/kexec-syscall.h:61: error: (Each undeclared identifier is reported only once kexec/kexec-syscall.h:61: error: for each function it appears in.) make: *** [kexec/kexec.o] Error 1 (no syscall no. defined in the kernel headers). Hmmm - the backup #ifdef __m68k__ does not appear to trigger, maybe it's __mc68000__ instead? See attached - not really enough yet, though: In file included from kexec/arch/m68k/kexec-m68k.c:19: kexec/arch/m68k/bootinfo.h:12: error: syntax error before __be16 kexec/arch/m68k/bootinfo.h:12: warning: no semicolon at end of struct or union kexec/arch/m68k/bootinfo.h:13: warning: type defaults to `int' in declaration of `size' kexec/arch/m68k/bootinfo.h:13: warning: data definition has no type or storage class kexec/arch/m68k/bootinfo.h:15: error: syntax error before __be32 kexec/arch/m68k/bootinfo.h:15: warning: no semicolon at end of struct or union kexec/arch/m68k/bootinfo.h:17: warning: type defaults to `int' in declaration of `machtype' kexec/arch/m68k/bootinfo.h:17: warning: data definition has no type or storage class kexec/arch/m68k/bootinfo.h:19: error: syntax error before __be32 kexec/arch/m68k/bootinfo.h:19: warning: no semicolon at end of struct or union kexec/arch/m68k/bootinfo.h:20: warning: type defaults to `int' in declaration of `size' kexec/arch/m68k/bootinfo.h:20: warning: data definition has no type or storage class kexec/arch/m68k/bootinfo.h:21: warning: type defaults to `int' in declaration of `mem_info' kexec/arch/m68k/bootinfo.h:21: warning: data definition has no type or storage class kexec/arch/m68k/bootinfo.h:23: error: syntax error before '}' token make: *** [kexec/arch/m68k/kexec-m68k.o] Error 1 Missing typedefs for __u16, __u32, __be16 and __be32 (the former two being present in /usr/include/asm/types.h but not picked up from there). Patch attached as well - may be harmful on more recent m68k installations. Untested, yet. Cheers, Michael From 546c34daf7100f529aa350b3adbf5d6bebf3 Mon Sep 17 00:00:00 2001 From: Michael Schmitz schm...@debian.org Date: Sat, 15 Mar 2014 12:59:29 +1300 Subject: [PATCH] Fix m68k default syscall #define Signed-off-by: Michael Schmitz schm...@debian.org --- kexec/kexec-syscall.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h index 6238044..92efbf2 100644 --- a/kexec/kexec-syscall.h +++ b/kexec/kexec-syscall.h @@ -118,7 +118,7 @@ static inline long kexec_load(void *entry, unsigned long nr_segments, #if defined(__mips__) #define KEXEC_ARCH_NATIVE KEXEC_ARCH_MIPS #endif -#ifdef __m68k__ +#if defined(__m68k__) || defined(__mc68000__) #define KEXEC_ARCH_NATIVE KEXEC_ARCH_68K #endif -- 1.5.6 From 22ba5a8482a7c4aeb0d154f5155b1623ac5830c6 Mon Sep 17 00:00:00 2001 From: Michael Schmitz schm...@debian.org Date: Sat, 15 Mar 2014 13:30:48 +1300 Subject: [PATCH] more m68k compile fixes Signed-off-by: Michael Schmitz schm...@debian.org --- kexec/arch/m68k/bootinfo.h | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/kexec/arch/m68k/bootinfo.h b/kexec/arch/m68k/bootinfo.h index b6f453d..33d36c1 100644 --- a/kexec/arch/m68k/bootinfo.h +++ b/kexec/arch/m68k/bootinfo.h @@ -3,6 +3,17 @@ #define DEFAULT_BOOTINFO_FILE /proc/bootinfo #define MAX_BOOTINFO_SIZE 1536 +/* + * These went missing from my m68k system - MSch + */ + +typedef unsigned short __u16; +typedef unsigned int__u32; + +typedef __u16 __le16; +typedef __u16 __be16; +typedef __u32 __le32; +typedef __u32 __be32; /* * Convenience overlay of several struct bi_record variants -- 1.5.6
Re: Improving Performance
Thorsten, Michael Schmitz dixit: I haven't found a way to tell ARAnyM to load the kernel to FastRAM, so this will need testing on real hardware, BOOTSTRA.TTP works on TOS/MiNT, IIRC. True, I just don't have TOS or MiNT installed on any ARAnyM disk image I have. (Neither do I have kexec tools yet - nice plug though, Geert! I definitely need to play with kexec.) Odd as it may sound - testing on the actual Falcon may be the quickest option after all :-) Cheers, Michael -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/532151b4.7020...@biophys.uni-duesseldorf.de
Re: Improving Performance
Hi Michael,
On Thu, Mar 13, 2014 at 7:35 AM, schmitz
schm...@biophys.uni-duesseldorf.de wrote:
(Neither do I have kexec tools yet - nice plug though, Geert! I definitely
need to play with kexec.)
git clone git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
cd kexec-tools
./bootstrap
./configure
make install
It has less build requirements than ARAnyM ;-)
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAMuHMdX5XW96NcDVxcr2DHS7L0+oCszRp0vUw8TEx=tnb+u...@mail.gmail.com
Re: Improving Performance
Andreas,
I haven't found a way to tell ARAnyM to load the kernel to FastRAM, so
this will need testing on real hardware,
Can you try this patch? Use [LILO] SkipSTRAM = true to enable.
Thanks for providing this patch - I will have to check whether I can get
all packages I need to compile ARAnyM on my PC (last time I tried, it
was a bit tricky).
Cheers,
Michael
Andreas.
diff --git a/src/bootos_linux.cpp b/src/bootos_linux.cpp
index 78adbb8..c0e55bb 100644
--- a/src/bootos_linux.cpp
+++ b/src/bootos_linux.cpp
@@ -409,7 +409,7 @@ int LinuxBootOs::checkKernel(void)
Elf32_Ehdr *kexec_elf; /* header of kernel executable */
Elf32_Phdr *kernel_phdrs;
unsigned long min_addr=0x, max_addr=0;
- unsigned long kernel_size, mem_ptr;
+ unsigned long kernel_size, mem_ptr, kernel_offset;
int i;
const char *kname, *kernel_name=vmlinux;
@@ -475,6 +475,10 @@ int LinuxBootOs::checkKernel(void)
kernel_size = max_addr - min_addr;
D(bug(lilo: kernel_size=%lu,kernel_size));
+ if (bx_options.lilo.skip_stram)
+ kernel_offset = FastRAMBase;
+ else
+ kernel_offset = 0;
mem_ptr = KERNEL_START;
for (i=0; iSDL_SwapBE16(kexec_elf-e_phnum); i++) {
unsigned long segment_length;
@@ -490,21 +494,29 @@ int LinuxBootOs::checkKernel(void)
}
segment_ptr = SDL_SwapBE32(kernel_phdrs[i].p_vaddr)-PAGE_SIZE;
- memcpy(((char *)RAMBaseHost) + mem_ptr + segment_ptr, ((char *) kexec_elf) + segment_offset, segment_length);
+ if (bx_options.lilo.skip_stram)
+ memcpy (FastRAMBaseHost + mem_ptr + segment_ptr, (char
*) kexec_elf + segment_offset, segment_length);
+ else
+ memcpy(RAMBaseHost + mem_ptr + segment_ptr, (char *)
kexec_elf + segment_offset, segment_length);
- D(bug(lilo: Copied segment %d: 0x%08x,0x%08x at 0x%08x,i,segment_offset,segment_length,mem_ptr+segment_ptr));
+ D(bug(lilo: Copied segment %d: 0x%08x,0x%08x at
0x%08x,i,segment_offset,segment_length,kernel_offset+mem_ptr+segment_ptr));
}
/*--- Copy the ramdisk after kernel (and reserved bootinfo) ---*/
if (ramdisk ramdisk_length) {
unsigned long rd_start;
unsigned long rd_len;
+ unsigned long rd_offset;
+ if (bx_options.lilo.skip_stram)
+ rd_offset = KERNEL_START + kernel_size + MAX_BI_SIZE;
+ else
+ rd_offset = 0;
rd_len = ramdisk_length - RAMDISK_FS_START;
- if (FastRAMSizerd_len) {
+ if (FastRAMSize rd_offset + rd_len) {
/* Load in FastRAM */
- rd_start = FastRAMBase;
- memcpy(FastRAMBaseHost, ((unsigned char *)ramdisk) +
RAMDISK_FS_START, rd_len);
+ rd_start = FastRAMBase + rd_offset;
+ memcpy(FastRAMBaseHost + rd_offset, (unsigned char
*)ramdisk + RAMDISK_FS_START, rd_len);
} else {
/* Load in ST-RAM */
rd_start = RAMSize - rd_len;
@@ -519,7 +531,7 @@ int LinuxBootOs::checkKernel(void)
for (i=0; i16; i++) {
uint32 *tmp;
- tmp = (uint32 *)(((unsigned char *)FastRAMBaseHost) /*+ rd_start*/ + 512);
+ tmp = (uint32 *)((unsigned char *)FastRAMBaseHost +
rd_offset + 512);
D(bug(lilo: ramdisk[%d]=0x%08x,i,
SDL_SwapBE32(tmp[i])));
}
#endif
@@ -557,7 +569,8 @@ int LinuxBootOs::checkKernel(void)
bi.mch_type = SDL_SwapBE32(ATARI_MACH_AB40);
bi.num_memory=0;
- ADD_CHUNK(0, RAMSize);
+ if (!bx_options.lilo.skip_stram)
+ ADD_CHUNK(0, RAMSize);
if (FastRAMSize0) {
ADD_CHUNK(FastRAMBase, FastRAMSize);
}
@@ -569,24 +582,30 @@ int LinuxBootOs::checkKernel(void)
}
/*--- Copy boot info in RAM ---*/
- memcpy(RAMBaseHost + KERNEL_START + kernel_size, bi_union.record,
bi_size);
-D(bug(lilo: bootinfo at 0x%08x,KERNEL_START + kernel_size));
+ if (bx_options.lilo.skip_stram)
+ memcpy(FastRAMBaseHost + KERNEL_START + kernel_size,
bi_union.record, bi_size);
+ else
+ memcpy(RAMBaseHost + KERNEL_START + kernel_size,
bi_union.record, bi_size);
+ D(bug(lilo: bootinfo at 0x%08x, kernel_offset + KERNEL_START +
kernel_size));
for (i=0; i16; i++) {
uint32 *tmp;
- tmp = (uint32 *)(((unsigned char *)RAMBaseHost) + KERNEL_START + kernel_size);
+ if (bx_options.lilo.skip_stram)
+ tmp = (uint32 *)((unsigned char *)FastRAMBaseHost +
KERNEL_START + kernel_size);
+ else
+ tmp = (uint32 *)((unsigned char *)RAMBaseHost +
KERNEL_START +
Re: Improving Performance
Geert,
On Tue, 11 Mar 2014, Michael Schmitz wrote:
People that need to use ST RAM because the have too little TT RAM, could
still use the -s kernel option and enable ST RAM for kernel.
Perhaps an option to specify the video RAM adress space is easier to
implement to the existing memory model?
The address space set aside for video still needs to be mapped. The current
stram_alloc() interface does reqire that mapping to be set up by the generic
memory map initialization first. That's what I mentioned below - I haven't
found a quick and easy way to change that at first glance. Suggestions welcome
- I can't spend much time on this at present.
Does the hack below (not even compile-tested) work? It maps pool_size
(default 1 MiB) of ST-RAM and makes the pool use that.
Sort of - boots with kernel in ST-RAM, but nothing shown on the screen.
SCSI appears to allocate DMA-able memory though:
Linux version 3.14.0-rc6-atari-164136-g430db49 (schmitz@xplor) (gcc
version 4.6
.3 (GCC) ) #189 Thu Mar 13 20:43:55 NZDT 2014
console [debug0] enabled
Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K
SCC_DMA S
CC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
Ignoring memory chunk at 0x0:0xe0 before the first chunk
Fix your bootloader or use a memfile to make use of this area!
On node 0 totalpages: 130688
free_area_init_node: node 0, pgdat 002b7490, node_mem_map 00372000
DMA zone: 1149 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 130688 pages, LIFO batch:31
atari_stram pool: size = 1048576 bytes, resource = [???
0x007f4000-0x008f3fff f
lags 0x0]
atari_stram pool: start = 7f4000, end = 8f3fff
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129539
atafb_init: start
atafb_init: initializing Falcon hw
atafb: screen_base 007f4000 real_screen_base 007f4000 screen_len 69632
Determined 640x400, depth 1
virtual 640x870
Console: switching to mono frame buffer device 80x25
fb0: frame buffer device, using 68K of video memory
Doesn't reboot cleanly, though. Machine is not recognized as a Falcon by
TOS on reboot (hard reboot sorts that out).
My version of your patch (minus verbosity additions) attached - booting
in ST-RAM still works as it should. I've left the normal case allocs in
atari_stram_reserve_pages(), and your change in atari_stram_init() for
simplicity. Should probably both go into the same function if possible.
More debugging of atafb needed - I have a hunch that the ioremapped
kernel virtual address is being used as physical address for atafb.
Need to batten down the hatches now - we expect cyclone Lusi to hit from
tomorrow.
Cheers,
Michael
Make sure the ST-RAM is not mentioned in your memfile.
diff --git a/arch/m68k/atari/stram.c b/arch/m68k/atari/stram.c
index e8e797e672e0..f658421e9a08 100644
--- a/arch/m68k/atari/stram.c
+++ b/arch/m68k/atari/stram.c
@@ -66,25 +66,17 @@ early_param(stram_pool, atari_stram_setup);
*/
void __init atari_stram_init(void)
{
- int i;
- void *stram_start;
-
/*
-* determine whether kernel code resides in ST-RAM
-* (then ST-RAM is the first memory block at virtual 0x0)
+* Skip page 0, as the fhe first 2 KiB are supervisor-only!
*/
- stram_start = phys_to_virt(0);
- kernel_in_stram = (stram_start == 0);
-return;
-
- for (i = 0; i m68k_num_memory; ++i) {
- if (m68k_memory[i].addr == 0) {
- return;
- }
- }
+ void *stram_start = ioremap(PAGE_SIZE, pool_size);
+
+ stram_pool.start = (resource_size_t)stram_start;
+ stram_pool.end = stram_pool.start + pool_size - 1;
+ request_resource(iomem_resource, stram_pool);
- /* Should never come here! (There is always ST-Ram!) */
- panic(atari_stram_init: no ST-RAM found!);
+ pr_debug(atari_stram pool: size = %lu bytes, resource = %pR\n,
+pool_size, stram_pool);
}
@@ -94,19 +86,6 @@ return;
*/
void __init atari_stram_reserve_pages(void *start_mem)
{
- /*
-* always reserve first page of ST-RAM, the first 2 KiB are
-* supervisor-only!
-*/
- if (!kernel_in_stram)
- reserve_bootmem(0, PAGE_SIZE, BOOTMEM_DEFAULT);
-
- stram_pool.start = (resource_size_t)alloc_bootmem_low_pages(pool_size);
- stram_pool.end = stram_pool.start + pool_size - 1;
- request_resource(iomem_resource, stram_pool);
-
- pr_debug(atari_stram pool: size = %lu bytes, resource = %pR\n,
-pool_size, stram_pool);
}
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.
Re: Improving Performance
Geert
(Neither do I have kexec tools yet - nice plug though, Geert! I definitely
need to play with kexec.)
git clone git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
cd kexec-tools
./bootstrap
./configure
make install
It has less build requirements than ARAnyM ;-)
Other than git (don't have that on the Falcon) :-)
Thanks, I'll give that a try.
Cheers,
Michael
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53216d20.6030...@biophys.uni-duesseldorf.de
Re: Improving Performance
Hi Michael,
On Thu, Mar 13, 2014 at 9:22 AM, schmitz
schm...@biophys.uni-duesseldorf.de wrote:
Does the hack below (not even compile-tested) work? It maps pool_size
(default 1 MiB) of ST-RAM and makes the pool use that.
Sort of - boots with kernel in ST-RAM, but nothing shown on the screen. SCSI
appears to allocate DMA-able memory though:
Ignoring memory chunk at 0x0:0xe0 before the first chunk
Haha, you still have it in the bootinfo. Fortunately Linux doesn't use it ;-)
More debugging of atafb needed - I have a hunch that the ioremapped kernel
virtual address is being used as physical address for atafb.
Indeed, atafb needs the physical address, so the ioremap() should be moved
from atari_stram_init() to atafb.
That'll complicate matters (kernel in ST-RAM vs. not), see further below.
There may be other virt/phys bugs in atafb, as before virt == phys for ST-RAM,
so conversion didn't matter.
screen_info.screen_base should be the virtual address,
fb_fix_info.smem_start should be the physical address.
For comparison, amiga_chip_alloc() always returns virtual addresses.
Conversion is done through ZTWO_VADDR()/ZTWO_PADDR(), which is
just an offset, as we always map the first 16 MiB using transparent translation.
Ah, perhaps you can do something similar? Hence keep the ioremap() in
atari_stram_init(), and provide helpers atari_stram_to_virt() and
atari_stram_to_phys() for phys/virt conversion?
The helpers can be no-ops if ST-RAM is not ioremapped().
That way the drivers don't need to know.
One other thing: for bookkeeping, it would be better if the pool is registered
using the physical addresses, as its resources will show up in /proc/iomem.
Hence:
stram_pool.start = PAGE_SIZE;
stram_pool.end = stram_pool.start + pool_size - 1;
stram_virt_offset = ioremap(stram_pool.start,
resource_len(stram_pool) - stram_pool.start;
and
void *atari_stram_to_virt(unsigned long phys)
{
return (void *)(phys + stram_virt_offset);
}
(if the kernel is in ST-RAM, stram_virt_offset should be 0);
and call atari_stram_to_virt() just before returning from atari_stram_alloc().
Same for the virt to phys conversion in atari_stram_free().
Need to batten down the hatches now - we expect cyclone Lusi to hit from
tomorrow.
Keep Lusi out. The only cyclones that belong near a hacker's house are Altera
Cyclones ;-)
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/camuhmdu55sfxr4-dy-l8yvwdqxdk0fdoy4h4jmszuod3qwc...@mail.gmail.com
Re: Improving Performance
schmitz dixit: BOOTSTRA.TTP works on TOS/MiNT, IIRC. True, I just don't have TOS or MiNT installed on any ARAnyM disk image I have. Just tell ARAnyM to use a host directory as C: for TOS/MiNT. It will not exist in Linux, but by then we won’t need it either ☺ (I’ve just used Afros as a base. Or the tarball from the guys from #atari-home. It’s been some time…) As for ARAnyM: apt-get source aranym; apt-get build-dep aranym ☻ bye, //mirabilos -- theftf Ich gebs zu, jupp ist cool -- theftf zu Natureshadow beim Fixen von Debian -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1403131430240.29...@herc.mirbsd.org
Re: Improving Performance
Geert,
might well work, and can be conditionalized to handle pool allocation
the old way if the kernel is in ST-RAM, and your way otherwise. Thanks
for coming up with this hack.
There's no memfile - ST-RAM is always ignored by mem_init if the kernel
is in FastRAM.
I haven't found a way to tell ARAnyM to load the kernel to FastRAM, so
this will need testing on real hardware,
Michael
On Tue, 11 Mar 2014, Michael Schmitz wrote:
People that need to use ST RAM because the have too little TT RAM,
could
still use the -s kernel option and enable ST RAM for kernel.
Perhaps an option to specify the video RAM adress space is easier to
implement to the existing memory model?
The address space set aside for video still needs to be mapped. The
current
stram_alloc() interface does reqire that mapping to be set up by the
generic
memory map initialization first. That's what I mentioned below - I
haven't
found a quick and easy way to change that at first glance.
Suggestions welcome
- I can't spend much time on this at present.
Does the hack below (not even compile-tested) work? It maps pool_size
(default 1 MiB) of ST-RAM and makes the pool use that.
Make sure the ST-RAM is not mentioned in your memfile.
diff --git a/arch/m68k/atari/stram.c b/arch/m68k/atari/stram.c
index e8e797e672e0..f658421e9a08 100644
--- a/arch/m68k/atari/stram.c
+++ b/arch/m68k/atari/stram.c
@@ -66,25 +66,17 @@ early_param(stram_pool, atari_stram_setup);
*/
void __init atari_stram_init(void)
{
- int i;
- void *stram_start;
-
/*
-* determine whether kernel code resides in ST-RAM
-* (then ST-RAM is the first memory block at virtual 0x0)
+* Skip page 0, as the fhe first 2 KiB are supervisor-only!
*/
- stram_start = phys_to_virt(0);
- kernel_in_stram = (stram_start == 0);
-return;
-
- for (i = 0; i m68k_num_memory; ++i) {
- if (m68k_memory[i].addr == 0) {
- return;
- }
- }
+ void *stram_start = ioremap(PAGE_SIZE, pool_size);
+
+ stram_pool.start = (resource_size_t)stram_start;
+ stram_pool.end = stram_pool.start + pool_size - 1;
+ request_resource(iomem_resource, stram_pool);
- /* Should never come here! (There is always ST-Ram!) */
- panic(atari_stram_init: no ST-RAM found!);
+ pr_debug(atari_stram pool: size = %lu bytes, resource = %pR\n,
+pool_size, stram_pool);
}
@@ -94,19 +86,6 @@ return;
*/
void __init atari_stram_reserve_pages(void *start_mem)
{
- /*
-* always reserve first page of ST-RAM, the first 2 KiB are
-* supervisor-only!
-*/
- if (!kernel_in_stram)
- reserve_bootmem(0, PAGE_SIZE, BOOTMEM_DEFAULT);
-
- stram_pool.start =
(resource_size_t)alloc_bootmem_low_pages(pool_size);
- stram_pool.end = stram_pool.start + pool_size - 1;
- request_resource(iomem_resource, stram_pool);
-
- pr_debug(atari_stram pool: size = %lu bytes, resource = %pR\n,
-pool_size, stram_pool);
}
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
https://lists.debian.org/
alpine.deb.2.02.1403110924010.29...@ayla.of.borg
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/f6446182f8bba93c21011252fa9d4...@biophys.uni-duesseldorf.de
Re: Improving Performance
Stefan, Adding an option to the atafb video driver make use of the SuperVidel hardware would be the easiest option. The SuperVidel base address is fixed, and it can use any chunk of FastRAM for frame buffer, presumably? The SuperVidel has 128MB Video RAM (DDR2 SDRAM): Thanks, that'll make it easier, we just need to ioremap a chunk of the video RAM. 0xA000 16MB - this is a shadow of ST RAM in DDR2 SDRAM Write access to ST RAM will be sniffed and done to the shadow RAM automagically. We can't write to ST-RAM if the kernel is in FastRAM, for now. The bus snooping is done for the entire 16 MB, in hardware? The atafb driver would need to keep well clear of that segment if ST-RAM is used by the kernel (i.e. kernel in ST-RAM). 0xA100 112MB - this is the general purpose Video/graphics RAM Can be read/write accessed as Byte/Word/Long Here you can find the SV memory map: http://hencox.dyndns.org/homepage/Self/SuperVidelMemoryMap.pdf Thanks, that might come in handy. In that case, it might be sufficient to change the fixed Videl base address to a variable one in the atafb driver, and perhaps use kmalloc instead of stram_alloc to allocate the frame buffer. If someone with access to this hardware is interested in giving this a try, I'd be happy to elaborate. Yeah, i'd be happy to try. OK, I'll have a look at the atafb code and try to see where it will need changes. Replacing stram_alloc by ioremap of a chunk at 0xA100 and hardcoding the Videl base address for that of the Supervidel (if necessary) is what I'd try first. (You'd need to compile your own kernels, and having a serial cable between the SCC modem port and some other computer for capturing kernel boot logs would be a clear bonus.) I can surely need a helping hand in this, (compile kernel) but i found someone who showed me how to set up a crosscompiler and kernelconfig. The last crosscompiler I got was from kernel.org, following a hint from Geert. I can provide a fairly minimal .config (for CT60, so no 030 support). Geert's Atari defconfig ought to be a good starting point, too. Cheers, Michael Will figure out. Thanks so far, Stefan -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531f0aa8.5000...@abbuc.de -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3fcaf4e28342ffc69bc2a3ac605d4...@biophys.uni-duesseldorf.de
Re: Improving Performance
On Wed, Mar 12, 2014 at 8:09 AM, Michael Schmitz
schm...@biophys.uni-duesseldorf.de wrote:
I haven't found a way to tell ARAnyM to load the kernel to FastRAM, so this
will need testing on real hardware,
You can, with kexec and a separate bootinfo file that contains TT RAM only.
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/camuhmdx9n9pgpuodwsw-dplnnks8ace2zjznzw-usmlhdl+...@mail.gmail.com
Re: Improving Performance
Geert Uytterhoeven ge...@linux-m68k.org writes: On Wed, Mar 12, 2014 at 8:09 AM, Michael Schmitz schm...@biophys.uni-duesseldorf.de wrote: I haven't found a way to tell ARAnyM to load the kernel to FastRAM, so this will need testing on real hardware, You can, with kexec and a separate bootinfo file that contains TT RAM only. Though it would be nice if the builtin lilo could do it directly. 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, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvmnpvzw@igel.home
Re: Improving Performance
Michael Schmitz dixit: I haven't found a way to tell ARAnyM to load the kernel to FastRAM, so this will need testing on real hardware, BOOTSTRA.TTP works on TOS/MiNT, IIRC. bye, //mirabilos -- mirabilos Owāte Jong… isch owāte disch gleisch… Natureshadow Ich kenn nur Oblate mirabilos Lernenz Platt Natureshadow Ich bin zu dick für Platt -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1403121212090.1...@herc.mirbsd.org
Re: Improving Performance
Stefan, Yes, the Falcon IDE is not too fast. But loading the OS needs 10 minutes. That can't honestly be the fault of a slow IDE bus. Just saying your comparison wasn't entirely fair. I wouldn't mind losing all ST RAM. The option to NOT load kernel into ST RAM is there, but it simply hangs. I guess this is because of the Atari tries to allocate video memory in ST RAM, which in this case is not accessible, correct? Correct. People that need to use ST RAM because the have too little TT RAM, could still use the -s kernel option and enable ST RAM for kernel. Perhaps an option to specify the video RAM adress space is easier to implement to the existing memory model? The address space set aside for video still needs to be mapped. The current stram_alloc() interface does reqire that mapping to be set up by the generic memory map initialization first. That's what I mentioned below - I haven't found a quick and easy way to change that at first glance. Suggestions welcome - I can't spend much time on this at present. There is an PCI bus upgrade to the Falcon, which enables tu use ATi Radeon 7500-9250 cards and there also exists (i have this) a Supervidel. Supervidel is an extension card to the Falcon 060 upgrade. Its register compatible to the original Videl graphics chip of Falcon 030. Both, ATi Radeon and SuperVidel have video RAM outside the ST RAM. Thus a kernel option like VRAM = adress would probably get it going... I'm aware of other video options - some will need to write the necessary code to make use of these. Adding an option to the atafb video driver make use of the SuperVidel hardware would be the easiest option. The SuperVidel base address is fixed, and it can use any chunk of FastRAM for frame buffer, presumably? In that case, it might be sufficient to change the fixed Videl base address to a variable one in the atafb driver, and perhaps use kmalloc instead of stram_alloc to allocate the frame buffer. If someone with access to this hardware is interested in giving this a try, I'd be happy to elaborate. (You'd need to compile your own kernels, and having a serial cable between the SCC modem port and some other computer for capturing kernel boot logs would be a clear bonus.) Cheers, Michael Greetings, Stefan Am 08.03.2014 00:19, schrieb Michael Schmitz: Stefan, your point regarding ST-RAM performance is well taken - in fact, it has been raised before. Repeatedly. What keeps us from placing the kernel in TT--RAM is the simple fact that under the current memory model used by m68k, we will lose all of ST-RAM for use by either the kernel or user space. Traditionally, the memory chunk that the kernel is located in will be the first chunk listed in the bootinfo, and also the first one to be initialized for use by the kernel. The currently employed memory model does require memory chunks to be in ascending order. ST-RAM as second chunk violates that assumption. There may be a way to make use of defined portions of ST-RAM as IO memory, but that has not been tested so far. I need to look into how much effort this would take. Switching to a different memory model will need someone to dig into the arcana of memory management - this ought to be possible to test on ARAnyM. Both Atari and Amifga stand to benefit from this, by the way. The port has recently procured RAM expansions for Amiga that don't work with the current memory model either, and need a different memory model for much the same reason. What we lack is someone with enough Linux and m68k memory management skills, apparently. Bear in mind that disk I/O on the Falcon is bound to be slower than on the Amigas (IDE on the slow bus vs. SCSI, I would presume). If you're feeling bold, give the Falcon SCSI driver a try, but please apply all of the recent patches posted to linux-m68k first. Cheers, Michael Am 08.03.2014 um 06:33 schrieb Stefan Niestegge: Hi debian/68k people, i know, while using Aranym for running debian-68k on Atari-compatible machine, it doesn't make a noticeable (if any) performance difference to boot the kernel with -s option (put Kernel in ST-RAM). But if you run it on a real 680x0 machine, which in my case is a Falcon with 100 MHz 68060 CPU, 512MB TT-RAM (read: FAST RAM, clocked at full CPU clock on a 32 bit bus) and 14MB ST-RAM (read: SLOW RAM, 16MHz on a 16bit bus), there is a huge performance loss. Last weekend i attended to a computer meeting, where someone ran debian-68k on his Amiga 1200 (Blizzard 1230 CPU upgrade, 50 MHz CPU clock, 64MB FAST RAM (but iirc on Blizzard 1230 RAM clock is half CPU clock). This machine _easily_ outperformed mine, though having much lower raw power. Wouldn't it be the right way to fix the Atari-branch kernel to get it running from TT RAM as on the Amiga? The Amigas 2 MB Chip RAM is not used by the linux kernel, only for video-RAM. If some developer lives halfway near me, i'd even lend him/her my
Re: Improving Performance
On Tue, 11 Mar 2014, Michael Schmitz wrote:
People that need to use ST RAM because the have too little TT RAM, could
still use the -s kernel option and enable ST RAM for kernel.
Perhaps an option to specify the video RAM adress space is easier to
implement to the existing memory model?
The address space set aside for video still needs to be mapped. The current
stram_alloc() interface does reqire that mapping to be set up by the generic
memory map initialization first. That's what I mentioned below - I haven't
found a quick and easy way to change that at first glance. Suggestions welcome
- I can't spend much time on this at present.
Does the hack below (not even compile-tested) work? It maps pool_size
(default 1 MiB) of ST-RAM and makes the pool use that.
Make sure the ST-RAM is not mentioned in your memfile.
diff --git a/arch/m68k/atari/stram.c b/arch/m68k/atari/stram.c
index e8e797e672e0..f658421e9a08 100644
--- a/arch/m68k/atari/stram.c
+++ b/arch/m68k/atari/stram.c
@@ -66,25 +66,17 @@ early_param(stram_pool, atari_stram_setup);
*/
void __init atari_stram_init(void)
{
- int i;
- void *stram_start;
-
/*
-* determine whether kernel code resides in ST-RAM
-* (then ST-RAM is the first memory block at virtual 0x0)
+* Skip page 0, as the fhe first 2 KiB are supervisor-only!
*/
- stram_start = phys_to_virt(0);
- kernel_in_stram = (stram_start == 0);
-return;
-
- for (i = 0; i m68k_num_memory; ++i) {
- if (m68k_memory[i].addr == 0) {
- return;
- }
- }
+ void *stram_start = ioremap(PAGE_SIZE, pool_size);
+
+ stram_pool.start = (resource_size_t)stram_start;
+ stram_pool.end = stram_pool.start + pool_size - 1;
+ request_resource(iomem_resource, stram_pool);
- /* Should never come here! (There is always ST-Ram!) */
- panic(atari_stram_init: no ST-RAM found!);
+ pr_debug(atari_stram pool: size = %lu bytes, resource = %pR\n,
+pool_size, stram_pool);
}
@@ -94,19 +86,6 @@ return;
*/
void __init atari_stram_reserve_pages(void *start_mem)
{
- /*
-* always reserve first page of ST-RAM, the first 2 KiB are
-* supervisor-only!
-*/
- if (!kernel_in_stram)
- reserve_bootmem(0, PAGE_SIZE, BOOTMEM_DEFAULT);
-
- stram_pool.start = (resource_size_t)alloc_bootmem_low_pages(pool_size);
- stram_pool.end = stram_pool.start + pool_size - 1;
- request_resource(iomem_resource, stram_pool);
-
- pr_debug(atari_stram pool: size = %lu bytes, resource = %pR\n,
-pool_size, stram_pool);
}
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, email to debian-68k-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/alpine.deb.2.02.1403110924010.29...@ayla.of.borg
Re: Improving Performance
Am 11.03.2014 07:14, schrieb Michael Schmitz: Stefan, Yes, the Falcon IDE is not too fast. But loading the OS needs 10 minutes. That can't honestly be the fault of a slow IDE bus. Just saying your comparison wasn't entirely fair. Ah, okay :) It was Amiga against Atari - never entirely fair, haha. There is an PCI bus upgrade to the Falcon, which enables tu use ATi Radeon 7500-9250 cards and there also exists (i have this) a Supervidel. Supervidel is an extension card to the Falcon 060 upgrade. Its register compatible to the original Videl graphics chip of Falcon 030. Both, ATi Radeon and SuperVidel have video RAM outside the ST RAM. Thus a kernel option like VRAM = adress would probably get it going... I'm aware of other video options - some will need to write the necessary code to make use of these. Adding an option to the atafb video driver make use of the SuperVidel hardware would be the easiest option. The SuperVidel base address is fixed, and it can use any chunk of FastRAM for frame buffer, presumably? The SuperVidel has 128MB Video RAM (DDR2 SDRAM): 0xA000 16MB - this is a shadow of ST RAM in DDR2 SDRAM Write access to ST RAM will be sniffed and done to the shadow RAM automagically. 0xA100 112MB - this is the general purpose Video/graphics RAM Can be read/write accessed as Byte/Word/Long Here you can find the SV memory map: http://hencox.dyndns.org/homepage/Self/SuperVidelMemoryMap.pdf In that case, it might be sufficient to change the fixed Videl base address to a variable one in the atafb driver, and perhaps use kmalloc instead of stram_alloc to allocate the frame buffer. If someone with access to this hardware is interested in giving this a try, I'd be happy to elaborate. Yeah, i'd be happy to try. (You'd need to compile your own kernels, and having a serial cable between the SCC modem port and some other computer for capturing kernel boot logs would be a clear bonus.) I can surely need a helping hand in this, (compile kernel) but i found someone who showed me how to set up a crosscompiler and kernelconfig. Will figure out. Thanks so far, Stefan -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531f0aa8.5000...@abbuc.de
Re: Improving Performance
Hi Michael, Yes, the Falcon IDE is not too fast. But loading the OS needs 10 minutes. That can't honestly be the fault of a slow IDE bus. I wouldn't mind losing all ST RAM. The option to NOT load kernel into ST RAM is there, but it simply hangs. I guess this is because of the Atari tries to allocate video memory in ST RAM, which in this case is not accessible, correct? People that need to use ST RAM because the have too little TT RAM, could still use the -s kernel option and enable ST RAM for kernel. Perhaps an option to specify the video RAM adress space is easier to implement to the existing memory model? There is an PCI bus upgrade to the Falcon, which enables tu use ATi Radeon 7500-9250 cards and there also exists (i have this) a Supervidel. Supervidel is an extension card to the Falcon 060 upgrade. Its register compatible to the original Videl graphics chip of Falcon 030. Both, ATi Radeon and SuperVidel have video RAM outside the ST RAM. Thus a kernel option like VRAM = adress would probably get it going... Greetings, Stefan Am 08.03.2014 00:19, schrieb Michael Schmitz: Stefan, your point regarding ST-RAM performance is well taken - in fact, it has been raised before. Repeatedly. What keeps us from placing the kernel in TT--RAM is the simple fact that under the current memory model used by m68k, we will lose all of ST-RAM for use by either the kernel or user space. Traditionally, the memory chunk that the kernel is located in will be the first chunk listed in the bootinfo, and also the first one to be initialized for use by the kernel. The currently employed memory model does require memory chunks to be in ascending order. ST-RAM as second chunk violates that assumption. There may be a way to make use of defined portions of ST-RAM as IO memory, but that has not been tested so far. I need to look into how much effort this would take. Switching to a different memory model will need someone to dig into the arcana of memory management - this ought to be possible to test on ARAnyM. Both Atari and Amifga stand to benefit from this, by the way. The port has recently procured RAM expansions for Amiga that don't work with the current memory model either, and need a different memory model for much the same reason. What we lack is someone with enough Linux and m68k memory management skills, apparently. Bear in mind that disk I/O on the Falcon is bound to be slower than on the Amigas (IDE on the slow bus vs. SCSI, I would presume). If you're feeling bold, give the Falcon SCSI driver a try, but please apply all of the recent patches posted to linux-m68k first. Cheers, Michael Am 08.03.2014 um 06:33 schrieb Stefan Niestegge: Hi debian/68k people, i know, while using Aranym for running debian-68k on Atari-compatible machine, it doesn't make a noticeable (if any) performance difference to boot the kernel with -s option (put Kernel in ST-RAM). But if you run it on a real 680x0 machine, which in my case is a Falcon with 100 MHz 68060 CPU, 512MB TT-RAM (read: FAST RAM, clocked at full CPU clock on a 32 bit bus) and 14MB ST-RAM (read: SLOW RAM, 16MHz on a 16bit bus), there is a huge performance loss. Last weekend i attended to a computer meeting, where someone ran debian-68k on his Amiga 1200 (Blizzard 1230 CPU upgrade, 50 MHz CPU clock, 64MB FAST RAM (but iirc on Blizzard 1230 RAM clock is half CPU clock). This machine _easily_ outperformed mine, though having much lower raw power. Wouldn't it be the right way to fix the Atari-branch kernel to get it running from TT RAM as on the Amiga? The Amigas 2 MB Chip RAM is not used by the linux kernel, only for video-RAM. If some developer lives halfway near me, i'd even lend him/her my (precious) Falcon to have hardware to test. I am on my way to write a good debian-68k install walkthrough for Atari Falcon, because its quite tricky to get it running. But with this poor performance, i don't know if its worth the effort. Any suggestions are very welcome, i have my Falcon set up on my main desk and latest debian-68k is installed. Network support works nicely. I even compiled my favorite console IRC client on it. greetings, Stefan -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531a0303.7000...@osnanet.de -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531b272c.2050...@abbuc.de
Re: Improving Performance
Sorry, this went into the thread here, was aimed to be a new one. Stefan -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531a0881.7010...@osnanet.de
Re: Improving Performance
Stefan, your point regarding ST-RAM performance is well taken - in fact, it has been raised before. Repeatedly. What keeps us from placing the kernel in TT--RAM is the simple fact that under the current memory model used by m68k, we will lose all of ST-RAM for use by either the kernel or user space. Traditionally, the memory chunk that the kernel is located in will be the first chunk listed in the bootinfo, and also the first one to be initialized for use by the kernel. The currently employed memory model does require memory chunks to be in ascending order. ST-RAM as second chunk violates that assumption. There may be a way to make use of defined portions of ST-RAM as IO memory, but that has not been tested so far. I need to look into how much effort this would take. Switching to a different memory model will need someone to dig into the arcana of memory management - this ought to be possible to test on ARAnyM. Both Atari and Amifga stand to benefit from this, by the way. The port has recently procured RAM expansions for Amiga that don't work with the current memory model either, and need a different memory model for much the same reason. What we lack is someone with enough Linux and m68k memory management skills, apparently. Bear in mind that disk I/O on the Falcon is bound to be slower than on the Amigas (IDE on the slow bus vs. SCSI, I would presume). If you're feeling bold, give the Falcon SCSI driver a try, but please apply all of the recent patches posted to linux-m68k first. Cheers, Michael Am 08.03.2014 um 06:33 schrieb Stefan Niestegge: Hi debian/68k people, i know, while using Aranym for running debian-68k on Atari-compatible machine, it doesn't make a noticeable (if any) performance difference to boot the kernel with -s option (put Kernel in ST-RAM). But if you run it on a real 680x0 machine, which in my case is a Falcon with 100 MHz 68060 CPU, 512MB TT-RAM (read: FAST RAM, clocked at full CPU clock on a 32 bit bus) and 14MB ST-RAM (read: SLOW RAM, 16MHz on a 16bit bus), there is a huge performance loss. Last weekend i attended to a computer meeting, where someone ran debian-68k on his Amiga 1200 (Blizzard 1230 CPU upgrade, 50 MHz CPU clock, 64MB FAST RAM (but iirc on Blizzard 1230 RAM clock is half CPU clock). This machine _easily_ outperformed mine, though having much lower raw power. Wouldn't it be the right way to fix the Atari-branch kernel to get it running from TT RAM as on the Amiga? The Amigas 2 MB Chip RAM is not used by the linux kernel, only for video-RAM. If some developer lives halfway near me, i'd even lend him/her my (precious) Falcon to have hardware to test. I am on my way to write a good debian-68k install walkthrough for Atari Falcon, because its quite tricky to get it running. But with this poor performance, i don't know if its worth the effort. Any suggestions are very welcome, i have my Falcon set up on my main desk and latest debian-68k is installed. Network support works nicely. I even compiled my favorite console IRC client on it. greetings, Stefan -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531a0303.7000...@osnanet.de -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/93b1215c8e15cb5da77afd7375e52...@biophys.uni-duesseldorf.de
