Atari TT (next)
Subsystems (2)
Hi all,
O.k. I'm passed the unexpected interrupt problem.
Now the next problem is that the console is all corrupted because atafb initializes and shows this...
atafb_init: startatafb_init: initializing TT hw
atafb: screen_base 0046e000 real_screen_base 0046e000 screen_len 311296 Determined 640x480, depth 4
virtual 640x972
Now, that screen_base is above 4MB, and I've only got 4MB STRAM.
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk Fix your bootloader or use a memfile to make use of this area!
I tried a memfile, but that just produces the same message.
I've read in some old threads about stram_swap=0 helping, but I don't see that implemented anymore.
Alan.
Hi Guys,
Quoted 5 lines
O.k. I'm passed the unexpected interrupt problem.
Now the next problem is that the console is all corrupted because atafb initializes and shows this...
Quoted 7 lines
atafb_init: startatafb_init: initializing TT hw
atafb:screen_base0046e000real_screen_base0046e000screen_len311296 Determined 640x480, depth 4
virtual 640x972Now, that
screen_baseis above 4MB, and I've only got 4MB STRAM.
You need to reserve ST-RAM for use by late initializing drivers - stram_pool=512k would be a good start. Not sure this works with only 4MB of ST-RAM though.
Quoted 6 lines
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk Fix your bootloader or use a memfile to make use of this area!
I tried a memfile, but that just produces the same message.
Looks like your kernel gets placed in TT-RAM (because of size?) and hence TT-RAM is listed as the first memory chunk. I don't think ataboot supports a memfile, so it remains the first chunk?
I've tried to play around with the MM init code to circumvent this in the past, to no avail. I think memory chunks have to be listed in strict order for MM init to work. I don't think reordering the memory chunk list once the kernel has started will work, so implementing the memfile option in ataboot may be necessary.
Cheers,
Michael
Quoted 8 lines
I've read in some old threads about stram_swap=0 helping, but I don't see that implemented anymore.
Alan.
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 12 lines · Michael Schmitz
Hi Guys,
Quoted 11 lines
O.k. I'm passed the unexpected interrupt problem.
Now the next problem is that the console is all corrupted because atafb initializes and shows this...
atafb_init: startatafb_init: initializing TT hw
atafb:screen_base0046e000real_screen_base0046e000screen_len311296 Determined 640x480, depth 4
virtual 640x972
Quoted 4 lines
Quoted 1 line
Now, that
screen_baseis above 4MB, and I've only got 4MB STRAM.You need to reserve ST-RAM for use by late initializing drivers - stram_pool=512k would be a good start. Not sure this works with only 4MB of ST-RAM though.
I saw this option and I don't understand why it even exists. ST-RAM is being sent by the bootloader with it's start (0) and size. ST-RAM always starts at 0. So it's perfectly detectable, so why the need for an option to specify the ST-RAM pool size ?
Quoted 10 lines
Quoted 6 lines
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk Fix your bootloader or use a memfile to make use of this area!
I tried a memfile, but that just produces the same message.
Looks like your kernel gets placed in TT-RAM (because of size?) and hence TT-RAM is listed as the first memory chunk. I don't think ataboot supports a memfile, so it remains the first chunk?
No, because I don't use "-s" on the bootloader. That means it loads the kernel in TTRAM.
Quoted 5 lines
I've tried to play around with the MM init code to circumvent this in the past, to no avail. I think memory chunks have to be listed in strict order for MM init to work. I don't think reordering the memory chunk list once the kernel has started will work, so implementing the memfile option in ataboot may be necessary.
I think anyone with ARanyM should be able to see this problem, by setting their STRAM to 4MB and removing the "-s" flag from the bootstra.tos app, to load the kernel in TTRAM.
Alan.
Quoted 12 lines · Michael Schmitz
Hi Guys,
Quoted 11 lines
O.k. I'm passed the unexpected interrupt problem.
Now the next problem is that the console is all corrupted because atafb initializes and shows this...
atafb_init: startatafb_init: initializing TT hw
atafb:screen_base0046e000real_screen_base0046e000screen_len311296 Determined 640x480, depth 4
virtual 640x972
Quoted 4 lines
Quoted 1 line
Now, that
screen_baseis above 4MB, and I've only got 4MB STRAM.You need to reserve ST-RAM for use by late initializing drivers - stram_pool=512k would be a good start. Not sure this works with only 4MB of ST-RAM though.
I saw this option and I don't understand why it even exists. ST-RAM is being sent by the bootloader with it's start (0) and size. ST-RAM always starts at 0. So it's perfectly detectable, so why the need for an option to specify the ST-RAM pool size ?
Quoted 10 lines
Quoted 6 lines
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk Fix your bootloader or use a memfile to make use of this area!
I tried a memfile, but that just produces the same message.
Looks like your kernel gets placed in TT-RAM (because of size?) and hence TT-RAM is listed as the first memory chunk. I don't think ataboot supports a memfile, so it remains the first chunk?
No, because I don't use "-s" on the bootloader. That means it loads the kernel in TTRAM.
Quoted 6 lines
I've tried to play around with the MM init code to circumvent this in the past, to no avail. I think memory chunks have to be listed in strict order for MM init to work. I don't think reordering the memory chunk list once the kernel has started will work, so implementing the memfile option in ataboot may be necessary.
I think anyone with ARanyM should be able to see this problem, by setting their STRAM to 4MB and removing the "-s" flag from the bootstra.tos app, to load the kernel in TTRAM.
Alan.
Hi Alan,
Quoted 7 lines
Quoted 3 lines
You need to reserve ST-RAM for use by late initializing drivers - stram_pool=512k would be a good start. Not sure this works with only 4MB of ST-RAM though.
I saw this option and I don't understand why it even exists. ST-RAM is being sent by the bootloader with it's start (0) and size. ST-RAM always starts at 0. So it's perfectly detectable, so why the need for an option to specify the ST-RAM pool size ?
The stram_pool option is just to reserve ST-RAM (DMA-capable) that would otherwise be used by the kernel for other purposes. Atari sets the DMA memory barrier to the entire memory size, which is wrong in the strict sense (but cannot be changed easily). Drivers like SCSI and atafb have to resort to a special purpose memory allocator in order to claim DMA capable memory.
For this option to work, ST-RAM first has to be accepted by memory init (i.e. it has to be in the first chunk). We might have to resort to reserving the entire ST-RAM for the kernel's use if the kernel is not residing in ST-RAM (breaking the above assumption). Something similar is done for Amiga chip RAM - exactly how does the chip RAM situation differ, Geert? Is chip RAM being claimed by mem_init or is it being left aside?
Come to think of it - does the TT video chipset actually require screen memory to reside in ST-RAM? If it's fully 32 bit addressed we should not have any problems with TT-RAM. The problems you see might be caused by a fault in the TT codepath in atafb - I'm unsure this has been tested since the last atafb rewrite.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk Fix your bootloader or use a memfile to make use of this area!
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
I tried a memfile, but that just produces the same message.
Looks like your kernel gets placed in TT-RAM (because of size?) and hence TT-RAM is listed as the first memory chunk. I don't think ataboot supports a memfile, so it remains the first chunk?
No, because I don't use "-s" on the bootloader. That means it loads the kernel in TTRAM.
That's what I meant - the kernel residing in TT-RAM automatically will map this chunk at kernel virtual address 0x0. Something in our mem_init logic prevents using RAM with a lower physical address than was used by the first chunk. I'm quoting from memory here - Roman Zippel might know the exact answer to this.
Can you try to have the kernel placed in ST-RAM?
Quoted 11 lines
Quoted 8 lines
I've tried to play around with the MM init code to circumvent this in the past, to no avail. I think memory chunks have to be listed in strict order for MM init to work. I don't think reordering the memory chunk list once the kernel has started will work, so implementing the memfile option in ataboot may be necessary.
I think anyone with ARanyM should be able to see this problem, by setting their STRAM to 4MB and removing the "-s" flag from the bootstra.tos app, to load the kernel in TTRAM.
You're right, this should be possible to test with ARAnyM - the behavior is not new though. Loading the kernel in TT-RAM has been problematic on the Falcon for a long time now.
Cheers,
Michael
Quoted 2 lines · Michael Schmitz
Come to think of it - does the TT video chipset actually require screen memory to reside in ST-RAM?
Yes. Only the SCSI-DMA and SCC-DMA chips can address TT-RAM.
Quoted 5 lines
That's what I meant - the kernel residing in TT-RAM automatically will map this chunk at kernel virtual address
0x0. Something in ourmem_initlogic prevents using RAM with a lower physical address than was used by the first chunk. I'm quoting from memory here - Roman Zippel might know the exact answer to this.
If the kernel resides in TT-RAM all of ST-RAM is supposed to be used by stram_alloc.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 23 lines · Michael Schmitz
Hi Alan,
Quoted 7 lines
Quoted 3 lines
You need to reserve ST-RAM for use by late initializing drivers - stram_pool=512k would be a good start. Not sure this works with only 4MB of ST-RAM though.
I saw this option and I don't understand why it even exists. ST-RAM is being sent by the bootloader with it's start (0) and size. ST-RAM always starts at 0. So it's perfectly detectable, so why the need for an option to specify the ST-RAM pool size ?
The
stram_pooloption is just to reserve ST-RAM (DMA-capable) that would otherwise be used by the kernel for other purposes. Atari sets the DMA memory barrier to the entire memory size, which is wrong in the strict sense (but cannot be changed easily). Drivers like SCSI and atafb have to resort to a special purpose memory allocator in order to claim DMA capable memory.For this option to work, ST-RAM first has to be accepted by memory init (i.e. it has to be in the first chunk). We might have to resort to reserving the entire ST-RAM for the kernel's use if the kernel is not residing in ST-RAM (breaking the above assumption). Something similar is done for Amiga chip RAM - exactly how does the chip RAM situation differ, Geert? Is chip RAM being claimed by
mem_initor is it being left aside?
Quoted 5 lines
Come to think of it - does the TT video chipset actually require screen memory to reside in ST-RAM? If it's fully 32 bit addressed we should not have any problems with TT-RAM. The problems you see might be caused by a fault in the TT codepath in atafb - I'm unsure this has been tested since the last atafb rewrite.
Looking at atafb, we always allocate FB memory from STRAM unless it's an external video card, i.e. VME, ISA etc.
Quoted 13 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk Fix your bootloader or use a memfile to make use of this area!
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
I tried a memfile, but that just produces the same message.
Looks like your kernel gets placed in TT-RAM (because of size?) and hence TT-RAM is listed as the first memory chunk. I don't think ataboot supports a memfile, so it remains the first chunk?
No, because I don't use "-s" on the bootloader. That means it loads the kernel in TTRAM.
Quoted 7 lines
That's what I meant - the kernel residing in TT-RAM automatically will map this chunk at kernel virtual address
0x0. Something in ourmem_initlogic prevents using RAM with a lower physical address than was used by the first chunk. I'm quoting from memory here - Roman Zippel might know the exact answer to this.Can you try to have the kernel placed in ST-RAM?
No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on the TT is pretty rare as the only other option is 10MB using the onboard 2MB and an 8MB upgrade board.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
I've tried to play around with the MM init code to circumvent this in the past, to no avail. I think memory chunks have to be listed in strict order for MM init to work. I don't think reordering the memory chunk list once the kernel has started will work, so implementing the memfile option in ataboot may be necessary.
Quoted 6 lines
Quoted 3 lines
I think anyone with ARanyM should be able to see this problem, by setting their STRAM to 4MB and removing the "-s" flag from the bootstra.tos app, to load the kernel in TTRAM.
You're right, this should be possible to test with ARAnyM - the behavior is not new though. Loading the kernel in TT-RAM has been problematic on the Falcon for a long time now.
Sure, but by default Falcon's have only 4MB ST-RAM too, and yes lots of people have 14MB of ST-RAM now, but it's not uncommon to have 4MB ST-RAM.
I'll dig in.
Alan.
Hi Alan,
Quoted 8 lines
Quoted 5 lines
Come to think of it - does the TT video chipset actually require screen memory to reside in ST-RAM? If it's fully 32 bit addressed we should not have any problems with TT-RAM. The problems you see might be caused by a fault in the TT codepath in atafb - I'm unsure this has been tested since the last atafb rewrite.
Looking at atafb, we always allocate FB memory from STRAM unless it's an external video card, i.e. VME, ISA etc.
That's right - but in your case ST-RAM is not being mapped at all so it can't be used. You will get a chunk of TT-RAM assigned to atafb (fallback in case there's no more ST-RAM), the framebuffer code will happily draw there but the shifter cannot access it.
Quoted 5 lines
Quoted 1 line
Can you try to have the kernel placed in ST-RAM?
No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on the TT is pretty rare as the only other option is 10MB using the onboard 2MB and an 8MB upgrade board.
You may have to pare the kernel down to the bare minimum (i.e. modularize about everything you don't need to boot to initrd). Not sure where the limit for this is these days.
Quoted 6 lines
Quoted 3 lines
You're right, this should be possible to test with ARAnyM - the behavior is not new though. Loading the kernel in TT-RAM has been problematic on the Falcon for a long time now.
Sure, but by default Falcon's have only 4MB ST-RAM too, and yes lots of people have 14MB of ST-RAM now, but it's not uncommon to have 4MB ST-RAM.
I think my Falcon is the only machine kernels have been tested on in the last few years - I've got 14MB ST-RAM so I was never affected. I had played with getting the kernel run in TT-RAM briefly but MM is not my strong suit so I never got anywhere.
Quoted 1 line
I'll dig in.
Much appreciated.
Michael
Quoted 7 lines · Michael Schmitz
Hi Alan,
Quoted 5 lines
Quoted 5 lines
Come to think of it - does the TT video chipset actually require screen memory to reside in ST-RAM? If it's fully 32 bit addressed we should not have any problems with TT-RAM. The problems you see might be caused by a fault in the TT codepath in atafb - I'm unsure this has been tested since the last atafb rewrite.
Quoted 6 lines
Quoted 2 lines
Looking at atafb, we always allocate FB memory from STRAM unless it's an external video card, i.e. VME, ISA etc.
That's right - but in your case ST-RAM is not being mapped at all so it can't be used. You will get a chunk of TT-RAM assigned to atafb (fallback in case there's no more ST-RAM), the framebuffer code will happily draw there but the shifter cannot access it.
I understand, but the STRAM allocator is broken. It gives out TT-RAM. It should never do that on a TT.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Can you try to have the kernel placed in ST-RAM?
No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on the TT is pretty rare as the only other option is 10MB using the onboard 2MB and an 8MB upgrade board.
You may have to pare the kernel down to the bare minimum (i.e. modularize about everything you don't need to boot to initrd). Not sure where the limit for this is these days.
Already tried that. Still too big, because we need buffers from STRAM too.
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
You're right, this should be possible to test with ARAnyM - the behavior is not new though. Loading the kernel in TT-RAM has been problematic on the Falcon for a long time now.
Sure, but by default Falcon's have only 4MB ST-RAM too, and yes lots of people have 14MB of ST-RAM now, but it's not uncommon to have 4MB ST-RAM.
Quoted 8 lines
I think my Falcon is the only machine kernels have been tested on in the last few years - I've got 14MB ST-RAM so I was never affected. I had played with getting the kernel run in TT-RAM briefly but MM is not my strong suit so I never got anywhere.
Quoted 1 line
I'll dig in.
Much appreciated.
No probs. I'll report back when I have something.
Alan.
Hi Alan,
Quoted 2 lines
I understand, but the STRAM allocator is broken. It gives out TT-RAM. It should never do that on a TT.
The ST-RAM allocator is used by a number of drivers, some of those could actually use TT-RAM fine. But making the allocator fail instead of returning TT-RAM would be an option.
Quoted 5 lines
Quoted 3 lines
You may have to pare the kernel down to the bare minimum (i.e. modularize about everything you don't need to boot to initrd). Not sure where the limit for this is these days.
Already tried that. Still too big, because we need buffers from STRAM too.
What buffers? Filesystem buffers should be fine in TT-RAM. atafb buffer requirement could be reduced by using a low-res video mode perhaps (just to get past this point initially).
Cheers,
Michael
Quoted 7 lines · Michael Schmitz
Hi Alan,
Quoted 2 lines
I understand, but the STRAM allocator is broken. It gives out TT-RAM. It should never do that on a TT.
The ST-RAM allocator is used by a number of drivers, some of those could actually use TT-RAM fine. But making the allocator fail instead of returning TT-RAM would be an option.
Yes, adding a flag to say ONLY_STRAM would work. But the function itself is called atari_stram_alloc()/free(). And if that goes allocating TT-RAM there's a function name problem there. Very confusing.
Quoted 8 lines
Quoted 4 lines
Quoted 3 lines
You may have to pare the kernel down to the bare minimum (i.e. modularize about everything you don't need to boot to initrd). Not sure where the limit for this is these days.
Already tried that. Still too big, because we need buffers from STRAM too.
What buffers? Filesystem buffers should be fine in TT-RAM. atafb buffer requirement could be reduced by using a low-res video mode perhaps (just to get past this point initially).
I'll try again as I probably didn't try after getting past the unexpected interrupt issue.
Alan.
Quoted 7 lines · Michael Schmitz
Hi Alan,
Quoted 2 lines
I understand, but the STRAM allocator is broken. It gives out TT-RAM. It should never do that on a TT.
The ST-RAM allocator is used by a number of drivers, some of those could actually use TT-RAM fine.
There is no point in calling atari_stram_alloc if you don't need ST-RAM. Of course, all uses are because they *can't* use TT-RAM.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Andreas,
Quoted 4 lines · Andreas Schwab
Quoted 2 lines · Michael Schmitz
Hi Alan,
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
I understand, but the STRAM allocator is broken. It gives out TT-RAM. It should never do that on a TT.
The ST-RAM allocator is used by a number of drivers, some of those could actually use TT-RAM fine.
There is no point in calling
atari_stram_allocif you don't need ST-RAM. Of course, all uses are because they *can't* use TT-RAM.
I stand corrected - we should indeed make it fail by default if no ST-RAM is available then.
Cheers,
Michael
Quoted 3 lines · Michael Schmitz
What buffers? Filesystem buffers should be fine in TT-RAM. atafb buffer requirement could be reduced by using a low-res video mode perhaps (just to get past this point initially).
O.k. I've managed to cut down the kernel and boot with atafb enabled and it works, using the stram_pool option.
Next problem is the SCSI controller.
I get......
Atari SCSI: resetting the SCSI bus... done
scsi0: options CAN_QUEUE=16 CMD_PER_LUN=8 SCAT-GAT=128 TAGGED-QUEUING=no HOSTID=7 generic options AUTOSENSE REAL DMA SCSI-2 TAGGED QUEUING generic release=7
scsi0 : Atari native SCSI
scsi0: aborting command
scsi 0:0:0:0: CDB: Inquiry: 12 00 00 00 24 00
NCR5380 core release=7.
NCR5380: coroutine isn't running.
scsi0: no currently connected command
scsi0: issue_queue
scsi0: disconnected_queue
scsi0: destination target 0, lun 0
command = 18 (0x12) 00 00 00 24 00
NCR5380 core release=7.
NCR5380: coroutine isn't running.
scsi0: no currently connected command
scsi0: issue_queue
scsi0: disconnected_queue
scsi0: destination target 0, lun 0
command = 18 (0x12) 00 00 00 24 00
scsi 0:0:0:0: Device offlined - not ready after error recovery
I'll start poking at this.
Alan.
It's o.k. a nice clean coldboot and things are well again. But a problem with my initrd I think with process "start-udev" ?
Where's the latest initrd for 3.1 kernels ?
Thanks folks..
I'm booting up the initrd right now :-)
Linux version 3.1.0-atari-00246-gbff0dc7-dirty (root@server) (gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #33 Mon Jan 9 01:12:42 GMT 2012
console [debug0] enabled
Atari hardware found: TT_SHIFTER ST_MFP TT_MFP TT_SCSI_DMA TT_SCSI YM2149 PCM SCC_DMA SCC VME SCU MICROWIRE TT_CLK FDC_SPEED ACSI OFFSET 0x0 size 0x400000
On node 0 totalpages: 1024free_area_init_node: node 0, pgdat 00200afc, node_mem_map 00230000
DMA zone: 9 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 1015 pages, LIFO batch:0
On node 1 totalpages: 32768free_area_init_node: node 1, pgdat 00201480, node_mem_map 00239030
DMA zone: 288 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 32480 pages, LIFO batch:7
initrd: 08d51a08 - 09000000atari_stram pool: size = 524288 bytes, resource = [??? 0x0035a000-0x003d9fff flags 0x0]
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 2 zonelists in Zone order, mobility grouping on. Total pages: 33495 Kernel command line: fb=false root=/dev/ram load_ramdisk=1 stram_pool=524288 console=tty video=atafb:ttmid debug=ser2 BOOT_IMAGE=vmlinux.gz
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 128244k/128244k available (1528k kernel code, 5308k data, 92k init) NR_IRQS:72
sys stat 0x14
vme stat 0x0
Console: colour dummy device 80x25
console [tty0] enabled
Calibrating delay loop... 7.21 BogoMIPS (lpj=36096)pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 687k freed
msgmni has been set to 255
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) io scheduler noop registered
io scheduler cfq registered (default)atafb_init: startatafb_init: initializing TT hwatari_stram_alloc: allocate 311296 bytesatari_stram_alloc: returning [??? 0x0035a000-0x003a5fff flags 0x0]
atafb: screen_base 0035a000 real_screen_base 0035a000 screen_len 311296 Determined 640x480, depth 4
virtual 640x972
Console: switching to colour frame buffer device 80x30
fb0: frame buffer device, using 304K of video memory Non-volatile memory driver v1.3
brd: module loaded
loop: module loaded
Atari SCSI: resetting the SCSI bus... done
scsi0: options CAN_QUEUE=16 CMD_PER_LUN=8 SCAT-GAT=128 TAGGED-QUEUING=no HOSTID=7 generic options AUTOSENSE REAL DMA SCSI-2 TAGGED QUEUING generic release=7
scsi0 : Atari native SCSI
scsi 0:0:0:0: Direct-Access SEAGATE ST34520N 1498 PQ: 0 ANSI: 2
eth0: Riebl-Card (without battery) at io 0xfe00fff0, mem 0xfe010000, irq 56, hwaddr 00:00:36:04:00:00
eth0: Warning: This is a default ethernet address!
Use "ifconfig hw ether ..." to set the address.atarilance.c: v1.3 04/04/96 [email protected] sd 0:0:0:0: [sda] 8888924 512-byte logical blocks: (4.55 GB/4.23 GiB) sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 93 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
mousedev: PS/2 mouse device common for all mice
WARNING: keyboard self test failed!
input: Atari Keyboard as /devices/virtual/input/input0
TCP cubic registered
NET: Registered protocol family 17
sda: AHDI sda1 sda2 sda3 XGM< sda4 sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
*** FORMAT ERROR *** FORMAT=0
Current process id is 768
BAD KERNEL TRAP: 00000000
Modules linked in:
PC: [<000029de>] flush_thread+0x8/0xe
SR: 2300 SP: 07de1e68 a2: 07ddc070
d0: 00000001 d1: 07ddb000 d2: 00220c50 d3: 00000001
d4: 00226e90 d5: 00000000 a0: 003f6660 a1: 00330310
Process start-udev (pid: 768, task=07ddc070)
Frame format=0
Stack from 07de1e9c:
23000007 0007239e 00000080 00000001 0022af40 07d3b080 08836ba0
07ddf200
80000002 07def600 000987b2 07d3b080 00000000 07de1fcc fffffff8
00000000
00000300 efb1a71c 07d3b080 001f614c 00032b28 00043fe4 00000000
07de1f30
00000020 00071d06 07ddc070 00220c50 efffff92 00000001 00002000
00071d2e
07d3b104 00000002 00000008 07d3b080 00358ad8 00000003 00071e7e
08fdaf7e
00071eb2 000716d0 00043fe4 00071710 07d3b080 07de1fcc 00000001
08835000
Call Trace: [<0007239e>] flush_old_exec+0x424/0x434
[<000987b2>] load_elf_binary+0x22c/0xc72
[<00032b28>] __request_module+0x0/0xfe
[<00043fe4>] module_put+0x0/0x24
[<00071d06>] get_arg_page+0x30/0x96
[<00220c50>] unlzma+0x284/0xc10
[<00002000>] _start+0x0/0x8
[<00071d2e>] get_arg_page+0x58/0x96
[<00071e7e>] copy_strings+0x112/0x168
[<00071eb2>] copy_strings+0x146/0x168
[<000716d0>] search_binary_handler+0x26/0x1be
[<00043fe4>] module_put+0x0/0x24
[<00071710>] search_binary_handler+0x66/0x1be
[<00071d6c>] copy_strings+0x0/0x168
[<00072896>] do_execve+0x14e/0x224
[<00002b24>] sys_execve+0x32/0x54
[<000025b8>] syscall+0x8/0xc
Code: 508f 265f 285f 4e75 598f 357c 0001 01c4 <f357> 588f 4e75 4e68 42a7
42a7 42a7 2f2f 0010 2f08 4878 0011 4eb9 0002 5382 4fef
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill init!
Call Trace: [<0017b77c>] panic+0x54/0x192
[<00008b00>] bindec+0x180/0x198
[<00027d42>] do_exit+0x72/0x52a
[<00008b00>] bindec+0x180/0x198
[<00028408>] do_group_exit+0x6a/0x8c
[<00008b00>] bindec+0x180/0x198
[<0002843e>] sys_exit_group+0x14/0x1a
[<00008b00>] bindec+0x180/0x198
[<000025b8>] syscall+0x8/0xc
[<00002024>] run_init_process+0x1c/0x22
[<0000205a>] init_post+0x30/0x9a
[<0007873e>] sys_dup+0x0/0x42
[<00216134>] kernel_init+0xe6/0xee
[<0021604e>] kernel_init+0x0/0xee
[<00001000>] kernel_pg_dir+0x0/0x1000
[<00002874>] kernel_thread+0x3a/0x4eAlan.
Quoted 5 lines · Alan Hourihane
*** FORMAT ERROR *** FORMAT=0
Current process id is 768
BAD KERNEL TRAP: 00000000Modules linked in: PC: [<000029de>] flush_thread+0x8/0xe
void flush_thread(void)
{
unsigned long zero = 0;
current->thread.fs = __USER_DS;
if (!FPU_IS_EMU)
asm volatile (".chip 68k/68881\n\t"
"frestore %0@\n\t"
".chip 68k" : : "a" (&zero));
}GCC is optimizing away the initialisation of zero, since nothing visible is using its value.
Andreas.
--------------------------->8----------------------------------------
Quoted 1 line
From
bbf7451db90fcec5eade9d8bc913b78829192b9cMon Sep 17 00:00:00 2001
From: Andreas Schwab <[email protected]>
Date: Mon, 9 Jan 2012 11:36:18 +0100
Subject: [PATCH] m68k: fix assembler constraint to prevent overeager gcc
optimisation
Passing the address of a variable as an operand to an asm statement doesn't mark the value of this variable as used, so gcc optimized its initialisation away. Fix this by using a "m" constraint instead.
--- arch/m68k/kernel/process_mm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
arch/m68k/kernel/process_mm.c +2 -2
@@ -189,8 +189,8 @@ void flush_thread(void) current->thread.fs = __USER_DS;if (!FPU_IS_EMU ) asmvolatile (".chip 68k/68881\n\t" -"frestore %0@\n\t" -".chip 68k" : :"a" (&zero)); +"frestore %0\n\t" +".chip 68k" : :"m" (zero)); }/*
Signature · 7 lines
1.7.8.3 -- Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 18 lines · Andreas Schwab
Quoted 5 lines · Alan Hourihane
*** FORMAT ERROR *** FORMAT=0
Current process id is 768
BAD KERNEL TRAP: 00000000Modules linked in: PC: [<000029de>] flush_thread+0x8/0xevoid
flush_thread(void){ unsigned long zero = 0; current->thread.fs = __USER_DS; if (!FPU_IS_EMU) asm volatile (".chip 68k/68881\n\t" "frestore %0@\n\t" ".chip 68k" : : "a" (&zero)); }
Quoted 2 lines
GCC is optimizing away the initialisation of zero, since nothing visible is using its value.
Great spot!
Seems this also needs massaging into process_no.c too.
But am I at a shell prompt :-)
Alan.
Geert Uytterhoeven
maintainerQuoted 52 lines · Andreas Schwab
Quoted 5 lines · Alan Hourihane
*** FORMAT ERROR *** FORMAT=0
Current process id is 768
BAD KERNEL TRAP: 00000000Modules linked in: PC: [<000029de>] flush_thread+0x8/0xevoid
flush_thread(void)
{
unsigned long zero = 0;current->thread.fs =
__USER_DS;
if (!FPU_IS_EMU)
asm volatile (".chip 68k/68881\n\t" "frestore %0@\n\t" ".chip 68k" : : "a" (&zero)); }GCC is optimizing away the initialisation of zero, since nothing visible is using its value.
Andreas.
--------------------------->8---------------------------------------- From
bbf7451db90fcec5eade9d8bc913b78829192b9cMon Sep 17 00:00:00 2001
From: Andreas Schwab <[email protected]>
Date: Mon, 9 Jan 2012 11:36:18 +0100
Subject: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisationPassing the address of a variable as an operand to an asm statement doesn't mark the value of this variable as used, so gcc optimized its initialisation away. Fix this by using a "m" constraint instead.
---
arch/m68k/kernel/process_mm.c | 4 ++--1 files changed, 2 insertions(+), 2 deletions(-)arch/m68k/kernel/process_mm.c +0
-0@@ -189,8 +189,8 @@ void flush_thread(void) current->thread.fs = __USER_DS; if (!FPU_IS_EMU)asm volatile (".chip 68k/68881\n\t"
- "frestore %0@\n\t"
- ".chip 68k" : : "a" (&zero));
+ "frestore %0\n\t"
+ ".chip 68k" : : "m" (zero)); }
Quoted 3 lines
/*
--
1.7.8.3
Thanks!
Tuomas: I think this will fix your problem, too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Quoted 52 lines · Geert Uytterhoeven
Quoted 51 lines · Andreas Schwab
Quoted 5 lines · Alan Hourihane
*** FORMAT ERROR *** FORMAT=0
Current process id is 768
BAD KERNEL TRAP: 00000000Modules linked in: PC: [<000029de>] flush_thread+0x8/0xevoid
flush_thread(void){ unsigned long zero = 0; current->thread.fs = __USER_DS; if (!FPU_IS_EMU) asm volatile (".chip 68k/68881\n\t" "frestore %0@\n\t" ".chip 68k" : : "a" (&zero)); }GCC is optimizing away the initialisation of zero, since nothing visible is using its value.
Andreas.
--------------------------->8----------------------------------------
Frombbf7451db90fcec5eade9d8bc913b78829192b9cMon Sep 17 00:00:00 2001
From: Andreas Schwab<[email protected]>
Date: Mon, 9 Jan 2012 11:36:18 +0100
Subject: [PATCH] m68k: fix assembler constraint to prevent overeager gcc
optimisationPassing the address of a variable as an operand to an asm statement doesn't mark the value of this variable as used, so gcc optimized its initialisation away. Fix this by using a "m" constraint instead.
--- arch/m68k/kernel/process_mm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)arch/m68k/kernel/process_mm.c +2
-2@@ -189,8 +189,8 @@ void flush_thread(void) current->thread.fs = __USER_DS;if (!FPU_IS_EMU ) asmvolatile (".chip 68k/68881\n\t" -"frestore %0@\n\t" -".chip 68k" : :"a" (&zero)); +"frestore %0\n\t" +".chip 68k" : :"m" (zero)); }
Quoted 7 lines
Quoted 3 lines
arch/m68k/kernel/process_mm.c +0
-1/* -- 1.7.8.3
Thanks!
Tuomas: I think this will fix your problem, too?
I'll stop nagging if it works. :)
Tuomas
PATCH 1/1 m68k: fix assembler constraint to prevent overeager gcc optimisation
In reply to Geert UytterhoevenPassing the address of a variable as an operand to an asm statement doesn't mark the value of this variable as used, so gcc may optimize its initialisation away. Fix this by using the "m" constraint instead.
--- arch/m68k/atari/config.c | 8 ++++---- arch/m68k/kernel/process_mm.c | 4 ++-- arch/m68k/kernel/process_no.c | 4 ++-- arch/m68k/kernel/traps.c | 36 +++++++++++++++++------------------- arch/m68k/mm/cache.c | 6 +++--- 5 files changed, 28 insertions(+), 30 deletions(-)
arch/m68k/atari/config.c +4 -4
@@ -415,9 +415,9 @@ void __init config_atari(void)* FDC val = 4 -> Supervisor only */ asmvolatile ("\n" " .chip 68030\n" -" pmove %0@,%/tt1\n" +" pmove %0,%/tt1\n" " .chip 68k" - : :"a" (&tt1_val)); + : :"m" (tt1_val)); }else { asmvolatile ("\n" " .chip 68040\n"
@@ -570,10 +570,10 @@ static void atari_reset(void) : "d0"); }else asmvolatile ("\n" -" pmove %0@,%%tc\n" +" pmove %0,%%tc\n" " jmp %1@" :/* no outputs */ - :"a" (&tc_val),"a" (reset_addr)); + :"m" (tc_val),"a" (reset_addr)); }
arch/m68k/kernel/process_mm.c +2 -2
@@ -189,8 +189,8 @@ void flush_thread(void) current->thread.fs = __USER_DS;if (!FPU_IS_EMU ) asmvolatile (".chip 68k/68881\n\t" -"frestore %0@\n\t" -".chip 68k" : :"a" (&zero)); +"frestore %0\n\t" +".chip 68k" : :"m" (zero)); }/*
arch/m68k/kernel/process_no.c +2 -2
@@ -163,8 +163,8 @@ void flush_thread(void)#ifdef CONFIG_FPU if (!FPU_IS_EMU ) asmvolatile (".chip 68k/68881\n\t" -"frestore %0@\n\t" -".chip 68k" : :"a" (&zero)); +"frestore %0\n\t" +".chip 68k" : :"m" (zero));#endif }
arch/m68k/kernel/traps.c +17 -19
@@ -552,13 +552,13 @@ static inline void bus_error030 (struct frame *fp)#ifdef DEBUG asmvolatile ("ptestr %3,%2@,#7,%0\n\t" -"pmove %%psr,%1@" - :"=a&" (desc) - :"a" (&temp),"a" (addr),"d" (ssw)); +"pmove %%psr,%1" + :"=a&" (desc),"=m" (temp) + :"a" (addr),"d" (ssw));#else asmvolatile ("ptestr %2,%1@,#7\n\t" -"pmove %%psr,%0@" - : :"a" (&temp),"a" (addr),"d" (ssw)); +"pmove %%psr,%0" + :"=m" (temp) :"a" (addr),"d" (ssw));#endif mmusr = temp;
@@ -605,20 +605,18 @@ static inline void bus_error030 (struct frame *fp) !(ssw &RW ) ?"write" :"read" , addr, fp->ptregs.pc, ssw); asmvolatile ("ptestr #1,%1@,#0\n\t" -"pmove %%psr,%0@" - :/* no outputs */ - :"a" (&temp),"a" (addr)); +"pmove %%psr,%0" + :"=m" (temp) + :"a" (addr)); mmusr = temp;printk ("level 0 mmusr is %#x\n" , mmusr);#if 0 - asmvolatile ("pmove %%tt0,%0@" - :/* no outputs */ - :"a" (&tlong)); + asmvolatile ("pmove %%tt0,%0" + :"=m" (tlong));printk ("tt0 is %#lx, " , tlong); - asmvolatile ("pmove %%tt1,%0@" - :/* no outputs */ - :"a" (&tlong)); + asmvolatile ("pmove %%tt1,%0" + :"=m" (tlong));printk ("tt1 is %#lx\n" , tlong);#endif #ifdef DEBUG
@@ -668,13 +666,13 @@ static inline void bus_error030 (struct frame *fp)#ifdef DEBUG asmvolatile ("ptestr #1,%2@,#7,%0\n\t" -"pmove %%psr,%1@" - :"=a&" (desc) - :"a" (&temp),"a" (addr)); +"pmove %%psr,%1" + :"=a&" (desc),"=m" (temp) + :"a" (addr));#else asmvolatile ("ptestr #1,%1@,#7\n\t" -"pmove %%psr,%0@" - : :"a" (&temp),"a" (addr)); +"pmove %%psr,%0" + :"=m" (temp) :"a" (addr));#endif mmusr = temp;
arch/m68k/mm/cache.c +3 -3
@@ -52,9 +52,9 @@ static unsigned long virt_to_phys_slow(unsigned long vaddr)unsigned long *descaddr; asmvolatile ("ptestr %3,%2@,#7,%0\n\t" -"pmove %%psr,%1@" - :"=a&" (descaddr) - :"a" (&mmusr),"a" (vaddr),"d" (get_fs ().seg)); +"pmove %%psr,%1" + :"=a&" (descaddr),"=m" (mmusr) + :"a" (vaddr),"d" (get_fs ().seg));if (mmusr & (MMU_I |MMU_B |MMU_L ))return 0 ; descaddr =phys_to_virt ((unsigned long )descaddr);
Signature · 7 lines
1.7.8.3 -- Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Geert Uytterhoeven
maintainerRe: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation
Quoted 3 lines · Andreas Schwab
Passing the address of a variable as an operand to an asm statement doesn't mark the value of this variable as used, so gcc may optimize its initialisation away. Fix this by using the "m" constraint instead.
Thanks! I'll apply and queue for -stable.
Quoted 14 lines
arch/m68k/kernel/process_mm.c +0
-0@@ -189,8 +189,8 @@ void flush_thread(void) current->thread.fs = __USER_DS; if (!FPU_IS_EMU)asm volatile (".chip 68k/68881\n\t"
- "frestore %0@\n\t"
- ".chip 68k" : : "a" (&zero));
+ "frestore %0\n\t"
+ ".chip 68k" : : "m" (zero)); }
Quoted 1 line
/*
This one was changed to:
| asm volatile ("frestore %0@" : : "a" (&zero) : "memory");
in v3.3-rc1.
I take it (but I prefer to ask, asm constraints always make me nervous) the "memory" is no longer needed with your fix?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Geert Uytterhoeven
maintainerRe: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation
Quoted 6 lines · Geert Uytterhoeven
Quoted 3 lines · Andreas Schwab
Passing the address of a variable as an operand to an asm statement doesn't mark the value of this variable as used, so gcc may optimize its initialisation away. Fix this by using the "m" constraint instead.
Thanks! I'll apply and queue for -stable.
BTW, is it reasonable to assume we never saw the problem before because there used to be a set_fs() call in flush_thread()?
Cfr. commit b7de110044b4e26adcb7b278d14da93133692ed7 ("m68k, exec:
remove redundant set_fs(USER_DS)"),
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=b7de110044b4e26adcb7b278d14da93133692ed7
That would mean it happens in 3.1 and later only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Re: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation
In reply to Geert UytterhoevenQuoted 2 lines · Geert Uytterhoeven
I take it (but I prefer to ask, asm constraints always make me nervous) the "memory" is no longer needed with your fix?
No, it isn't.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Hi Alan,
Quoted 2 lines
Next problem is the SCSI controller.
My absolute favourite.
Quoted 11 lines
NCR5380 core release=7.
NCR5380: coroutine isn't running.
scsi0: no currently connected command
scsi0:issue_queue
scsi0:disconnected_queue
scsi0: destination target 0, lun 0
command = 18 (0x12) 00 00 00 24 00scsi 0:0:0:0: Device offlined - not ready after error recovery
I'll start poking at this.
If you can get the error recovery sorted, I'd be happy to start poking at Falcon SCSI again.
(Yes, I know a cold boot sorted it for now - just in case you can get it to get stuck again)
Congrats to getting this far at least - I have no idea on the initrd though.
Cheers,
Michael
Quoted 3 lines · Michael Schmitz <schmitzmic <at> googlemail.com> writes:
Quoted 3 lines
Quoted 1 line
Can you try to have the kernel placed in ST-RAM?
No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on
The guys at the Atari booth at OpenRheinRuhr had the same problem, they also had a 4/4 MiB split.
Quoted 3 lines
You may have to pare the kernel down to the bare minimum (i.e. modularize about everything you don't need to boot to initrd). Not sure where the limit for this is these days.
Note that the Debian kernel does not use initrd to boot (to the finally installed system), especially as those tools are built with klibc, which is currently still broken on m68k, and thus contains everything needed to get into an ext3fs / from disc, and then some. I don’t think you should be using a distro kernel made under such constraints (nor should the distro kernel be stripped more down considering the problems; I think there may even be flavours that don’t _support_ initrd, outside the image that is) but compile a stripped-down one yourself.
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
You're right, this should be possible to test with ARAnyM - the behavior is not new though. Loading the kernel in TT-RAM has been problematic on the Falcon for a long time now.
I don’t know about that; ARanyM has a built-in LILO, so I never saw any TOS (except when using AfrOS, but that’s a whole different beast)…
bye,
//mirabilos
Hi Thorsten,
Quoted 3 lines
Quoted 1 line
Quoted 1 line
No, the kernel is too big. I've only got 4MB ST-RAM. And getting more on
The guys at the Atari booth at OpenRheinRuhr had the same problem, they also had a 4/4 MiB split.
OK, worth fixing in this case.
Considering the kernel may fit into the first 4 MB, how much room does that leave for RAM allocated through stram_alloc? Do we need to set aside some RAM right at the end of the kernel code segment for things like atafb (like we used to do in 2.2 or thereabouts)?
Quoted 6 lines
Quoted 3 lines
You may have to pare the kernel down to the bare minimum (i.e. modularize about everything you don't need to boot to initrd). Not sure where the limit for this is these days.
Note that the Debian kernel does not use initrd to boot (to the finally installed system), especially as those tools are built with klibc, which is currently still broken on m68k, and thus
I wasn't aware of that.
Quoted 6 lines
contains everything needed to get into an ext3fs / from disc, and then some. I don’t think you should be using a distro kernel made under such constraints (nor should the distro kernel be stripped more down considering the problems; I think there may even be flavours that don’t _support_ initrd, outside the image that is) but compile a stripped-down one yourself.
That's what I was suggesting - a stripped down kernel tailored to the TT could then be 'distributed' (like you do with other stuff from your people.d.o page) to those that need it.
Not that a total of 8 MB RAM would be a lot of fun to run today's kernel and userland on.
Cheers,
Michael
Quoted 5 lines · Michael Schmitz <schmitzmic <at> googlemail.com> writes:
Quoted 3 lines
Note that the Debian kernel does not use initrd to boot (to the finally installed system), especially as those tools are built with klibc, which is currently still broken on m68k, and thus
I wasn't aware of that.
Yeah. I have started trying to fix that, though ☺ see the other mail of today.
Quoted 5 lines
That's what I was suggesting - a stripped down kernel tailored to the TT could then
be 'distributed' (like you do with other stuff from your people.d.o page) to those
that need it.
That would indeed be possible and not too hard (Debian has tools for that, and if must, these could even be cross-built).
Quoted 2 lines
Not that a total of 8 MB RAM would be a lot of fun to run today's kernel and userland on.
Indeed. I did that for a friend’s i486 laptop, and I’ve got one of those myself as well except it has 12 MiB. MirBSD works – barely. (I could go multiuser on the 12 MiB RAM one, but decided to not do it; it’s enough for 3 virtual consoles, GNU screen, lynx, ssh client, tinyirc. Not my regular IRC client sirc, as that one’s written in Perl. So, definitively no stock Linux distribution…)
bye,
//mirabilos
Geert Uytterhoeven
maintainerQuoted 9 lines · Thorsten Glaser
Quoted 2 lines
Not that a total of 8 MB RAM would be a lot of fun to run today's kernel and userland on.
Indeed. I did that for a friend’s i486 laptop, and I’ve got one of those myself as well except it has 12 MiB. MirBSD works – barely. (I could go multiuser on the 12 MiB RAM one, but decided to not do it; it’s enough for 3 virtual consoles, GNU screen, lynx, ssh client, tinyirc. Not my regular IRC client sirc, as that one’s written in Perl. So, definitively no stock Linux distribution…)
Don't tell me. My Amiga also has only 12 MiB of Fast RAM. Where are the days my Amiga was mailserver for 70 people, many of them logging in remotely to read their email with pine? Debian is getted too bloated, I have less packages (incl.daemons) installed than 12 years ago, but the system is still much slower.
I really need more time to work on an OpenWRT-based solution ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Geert Uytterhoeven dixit:
Quoted 3 lines
Don't tell me. My Amiga also has only 12 MiB of Fast RAM. Where are the days my Amiga was mailserver for 70 people, many of them logging in remotely to read their email with pine? Debian is getted too bloated,
;-)
It’s not just that. XFree86 4, for example, is a memory hog compared to XF86 3, and Unicode support eats up lots and lots of RAM.
Quoted 2 lines
I have less packages (incl.daemons) installed than 12 years ago, but the system is still much slower.
Hm, slower too?
On the other hand, in the time since I started with m68k, I think it got faster (except compiling gcc itself, but that was to be expected) and, even more important, more responsible.
Quoted 1 line
I really need more time to work on an OpenWRT-based solution ;-)
Or FreeWRT, or OpenADK, or… ;-)
bye,
//mirabilos
Signature · 3 lines
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward BurrGeert Uytterhoeven
maintainerQuoted 9 lines · Thorsten Glaser
Geert Uytterhoeven dixit:
Quoted 3 lines
Don't tell me. My Amiga also has only 12 MiB of Fast RAM. Where are the days my Amiga was mailserver for 70 people, many of them logging in remotely to read their email with pine? Debian is getted too bloated,
;-)
It’s not just that. XFree86 4, for example, is a memory hog compared to XF86 3, and Unicode support eats up lots and lots of RAM.
xserver-xfbdev based on kdrive still exists, right?
But AFAIK it lacks Amiga and Atari frame buffer device support. Fixing that has been on my list for a looooong time...
Quoted 4 lines
Quoted 2 lines
I have less packages (incl.daemons) installed than 12 years ago, but the system is still much slower.
Hm, slower too?
Yep. No free RAM, so everything causes swapping.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Geert Uytterhoeven
maintainerQuoted 6 lines · Michael Schmitz
For this option to work, ST-RAM first has to be accepted by memory init (i.e. it has to be in the first chunk). We might have to resort to reserving the entire ST-RAM for the kernel's use if the kernel is not residing in ST-RAM (breaking the above assumption). Something similar is done for Amiga chip RAM - exactly how does the chip RAM situation differ, Geert? Is chip RAM being claimed by
mem_initor is it being left aside?
Chip RAM is different in that Linux (unlike AmigaOS) doesn't use it as system RAM.
Being on the Zorro II bus (first 16 MiB), it's slow on most machines and doesn't support RMW cycles (needed for page tables) on Zorro III-capable machines. In general, we don't use Z2 RAM as system memory on Z3 capable machines.
Quoted 5 lines
Come to think of it - does the TT video chipset actually require screen memory to reside in ST-RAM? If it's fully 32 bit addressed we should not have any problems with TT-RAM. The problems you see might be caused by a fault in the TT codepath in atafb - I'm unsure this has been tested since the last atafb rewrite.
static void set_screen_base(void *s_base)
{
unsigned long addr;
addr = virt_to_phys(s_base);
/* Setup Screen Memory */
shifter.bas_hi = (unsigned char)((addr & 0xff0000) >> 16);
shifter.bas_md = (unsigned char)((addr & 0x00ff00) >> 8);
shifter.bas_lo = (unsigned char)(addr & 0x0000ff);
}It's limited to 24-bit addresses.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Geert,
Quoted 9 lines
Quoted 3 lines
ST-RAM (breaking the above assumption). Something similar is done for Amiga chip RAM - exactly how does the chip RAM situation differ, Geert? Is chip RAM being claimed by
mem_initor is it being left aside?Chip RAM is different in that Linux (unlike AmigaOS) doesn't use it as system RAM.
Being on the Zorro II bus (first 16 MiB), it's slow on most machines and doesn't support RMW cycles (needed for page tables) on Zorro III-capable machines. In general, we don't use Z2 RAM as system memory on Z3 capable machines.
But is its physical address lower than the kernel segment's, as in this case?
(thanks to Andreas for the discontigmem commit pointer ... )
Quoted 1 line
It's limited to 24-bit addresses.
Thanks, that's what I could not find on the spot.
Looks like we'll have to fix the bootstrap or our discontig memory support. Is there a strict requirement (from the kernel's early startup and mem_init POV) that the kernel has to reside in the first bootinfo memory chunk?
Cheers,
Michael
Geert Uytterhoeven
maintainerHi Michael,
Quoted 11 lines · Michael Schmitz
Quoted 9 lines
Quoted 3 lines
ST-RAM (breaking the above assumption). Something similar is done for Amiga chip RAM - exactly how does the chip RAM situation differ, Geert? Is chip RAM being claimed by
mem_initor is it being left aside?Chip RAM is different in that Linux (unlike AmigaOS) doesn't use it as system RAM.
Being on the Zorro II bus (first 16 MiB), it's slow on most machines and doesn't support RMW cycles (needed for page tables) on Zorro III-capable machines. In general, we don't use Z2 RAM as system memory on Z3 capable machines.But is its physical address lower than the kernel segment's, as in this case?
Yes, Zorro II space is the first 16 MiB.
But it's handled completely separately from system RAM. Its mapping is set up in mmu_init_amiga() in head.S.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Geert,
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Being on the Zorro II bus (first 16 MiB), it's slow on most machines and doesn't support RMW cycles (needed for page tables) on Zorro III-capable machines. In general, we don't use Z2 RAM as system memory on Z3 capable machines.
But is its physical address lower than the kernel segment's, as in this case?
Yes, Zorro II space is the first 16 MiB.
Thanks, so there would be a similar situation where Z2 RAM would not be accessible to mem_init on Amiga.
Quoted 2 lines
But it's handled completely separately from system RAM. Its mapping is set up in
mmu_init_amiga()inhead.S.
Looks like we may need to do the same for the TT then.
Cheers,
Michael
Quoted 4 lines · Michael Schmitz
Looks like we'll have to fix the bootstrap or our discontig memory support. Is there a strict requirement (from the kernel's early startup and
mem_initPOV) that the kernel has to reside in the first bootinfo memory chunk?
It is a requirement that the kernel is mapped at virtual address zero since it is not relocatable.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Hi Andreas,
Quoted 6 lines
Quoted 3 lines
support. Is there a strict requirement (from the kernel's early startup and
mem_initPOV) that the kernel has to reside in the first bootinfo memory chunk?It is a requirement that the kernel is mapped at virtual address zero since it is not relocatable.
That much I understand - but can we tweak the bootinfo to report the chunks in physical address order? What I mean to say is - does the first bootinfo chunk get mapped at virtual address zero always, or is there some check to see what physical address corresponds to the kernel segment?
Cheers,
Michael
Quoted 7 lines · Michael Schmitz
Hi Andreas,
Quoted 5 lines
Quoted 3 lines
support. Is there a strict requirement (from the kernel's early startup and
mem_initPOV) that the kernel has to reside in the first bootinfo memory chunk?It is a requirement that the kernel is mapped at virtual address zero since it is not relocatable.
Quoted 8 lines
That much I understand - but can we tweak the bootinfo to report the chunks in physical address order? What I mean to say is - does the first bootinfo chunk get mapped at virtual address zero always, or is there some check to see what physical address corresponds to the kernel segment?
From what I can see the first
mem_infostruct is always mapped at VA 0
which is done in paging_init() in mm/motorola.c
Alan.
Hi Alan,
Quoted 9 lines
Quoted 6 lines
That much I understand - but can we tweak the bootinfo to report the chunks in physical address order? What I mean to say is - does the first bootinfo chunk get mapped at virtual address zero always, or is there some check to see what physical address corresponds to the kernel segment?
From what I can see the first
mem_infostruct is always mapped at VA 0 which is done inpaging_init()inmm/motorola.c
Thanks - I've got no kernel tree in front of me (no m68k hacking while at work) so I'm working from (fuzzy) memory only.
Meaning the kernel has to reside in the first chunk then. B*gger.
OK, let's assume we
1) reorder the mem chunks in PA order
2) keep note which was the first chunk initially, and map that one to VA 0 (instead of the first reordered one)
Does this break any assumptions in paging_init?
Cheers,
Michael
Quoted 10 lines · Alan Hourihane
Now the next problem is that the console is all corrupted because atafb initializes and shows this...
atafb_init: startatafb_init: initializing TT hw
atafb:screen_base0046e000real_screen_base0046e000screen_len311296 Determined 640x480, depth 4
virtual 640x972Now, that
screen_baseis above 4MB, and I've only got 4MB STRAM.
screen_base is a virtual address, the physical address is actually 0x146e000.
Quoted 3 lines
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk
Since 12d810c1b8c2b913d48e629e2b5c01d105029839 (m68k: discontinuous memory support) there is no longer support for memory regions with physical addresses that are out of order. Before that, if the kernel was loaded to TT-RAM the ST-RAM was virtually mapped just after TT-RAM.
Andreas.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Quoted 11 lines · Andreas Schwab
Quoted 9 lines · Alan Hourihane
Now the next problem is that the console is all corrupted because atafb initializes and shows this...
atafb_init: startatafb_init: initializing TT hw
atafb:screen_base0046e000real_screen_base0046e000screen_len311296 Determined 640x480, depth 4
virtual 640x972
Quoted 3 lines
Quoted 1 line
Now, that
screen_baseis above 4MB, and I've only got 4MB STRAM.
screen_baseis a virtual address, the physical address is actually0x146e000.
I thought that might be the case, given the TTRAM segment offset. But still, it's in the wrong area.
Quoted 8 lines
Quoted 3 lines
But there's also this further up the boot log.
Ignoring memory chunk at 0x0:0x400000 before the first chunk
Since
12d810c1b8c2b913d48e629e2b5c01d105029839(m68k: discontinuous memory support) there is no longer support for memory regions with physical addresses that are out of order. Before that, if the kernel was loaded to TT-RAM the ST-RAM was virtually mapped just after TT-RAM.
Thanks for the pointer.
Alan.
Hi Andreas,
Quoted 6 lines
Quoted 1 line
Ignoring memory chunk at 0x0:0x400000 before the first chunk
Since
12d810c1b8c2b913d48e629e2b5c01d105029839(m68k: discontinuous memory support) there is no longer support for memory regions with physical addresses that are out of order. Before that, if the kernel was loaded to TT-RAM the ST-RAM was virtually mapped just after TT-RAM.
Thanks - do we need a new memory model for this now?
Cheers,
Michael
Geert Uytterhoeven
maintainerQuoted 1 line · Alan Hourihane
O.k. I'm passed the unexpected interrupt problem.
BTW, what was wrong?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Quoted 4 lines · Geert Uytterhoeven
Quoted 1 line · Alan Hourihane
O.k. I'm passed the unexpected interrupt problem.
BTW, what was wrong?
It wasn't TT_MFP_TIMD, it was actually the first VME software interrupt.
I'll get a patch together when I've confirmed it working with atafb, when that's working too :-)
Alan.