* Atari TT (next)
@ 2012-01-07 1:27 Alan Hourihane
2012-01-07 6:47 ` Michael Schmitz
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Alan Hourihane @ 2012-01-07 1:27 UTC (permalink / raw)
To: Linux/m68k
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: start
atafb_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.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-07 1:27 Atari TT (next) Alan Hourihane
@ 2012-01-07 6:47 ` Michael Schmitz
2012-01-07 16:59 ` Alan Hourihane
2012-01-08 0:46 ` Alan Hourihane
2012-01-08 13:36 ` Andreas Schwab
2012-01-08 17:45 ` Geert Uytterhoeven
2 siblings, 2 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-07 6:47 UTC (permalink / raw)
To: Alan Hourihane; +Cc: Linux/m68k
Hi Guys,
> 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: start
> atafb_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.
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.
> 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
> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-07 6:47 ` Michael Schmitz
@ 2012-01-07 16:59 ` Alan Hourihane
2012-01-08 0:46 ` Alan Hourihane
1 sibling, 0 replies; 43+ messages in thread
From: Alan Hourihane @ 2012-01-07 16:59 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Linux/m68k
On 07/01/12 06:47, Michael Schmitz wrote:
> Hi Guys,
>> 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: start
>> atafb_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.
> 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 ?
>> 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.
> 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.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-07 6:47 ` Michael Schmitz
2012-01-07 16:59 ` Alan Hourihane
@ 2012-01-08 0:46 ` Alan Hourihane
2012-01-08 4:13 ` Michael Schmitz
1 sibling, 1 reply; 43+ messages in thread
From: Alan Hourihane @ 2012-01-08 0:46 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Linux/m68k
On 07/01/12 06:47, Michael Schmitz wrote:
> Hi Guys,
>> 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: start
>> atafb_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.
> 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 ?
>> 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.
> 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.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 0:46 ` Alan Hourihane
@ 2012-01-08 4:13 ` Michael Schmitz
2012-01-08 9:35 ` Andreas Schwab
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-08 4:13 UTC (permalink / raw)
To: Alan Hourihane; +Cc: Michael Schmitz, Linux/m68k, Geert Uytterhoeven
Hi Alan,
>> 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.
>
>>> 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.
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?
>
>
>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 4:13 ` Michael Schmitz
@ 2012-01-08 9:35 ` Andreas Schwab
2012-01-08 9:42 ` Alan Hourihane
2012-01-08 10:20 ` Geert Uytterhoeven
2 siblings, 0 replies; 43+ messages in thread
From: Andreas Schwab @ 2012-01-08 9:35 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Alan Hourihane, Linux/m68k, Geert Uytterhoeven
Michael Schmitz <schmitzmic@googlemail.com> writes:
> 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.
> 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.
If the kernel resides in TT-RAM all of ST-RAM is supposed to be used by
stram_alloc.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 4:13 ` Michael Schmitz
2012-01-08 9:35 ` Andreas Schwab
@ 2012-01-08 9:42 ` Alan Hourihane
2012-01-08 23:51 ` Michael Schmitz
2012-01-08 10:20 ` Geert Uytterhoeven
2 siblings, 1 reply; 43+ messages in thread
From: Alan Hourihane @ 2012-01-08 9:42 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Linux/m68k, Geert Uytterhoeven
On 08/01/12 04:13, Michael Schmitz wrote:
> Hi Alan,
>>> 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.
Looking at atafb, we always allocate FB memory from STRAM unless it's an
external video card, i.e. VME, ISA etc.
>>
>>>> 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.
> 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?
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.
>
>>
>>
>>> 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.
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.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 4:13 ` Michael Schmitz
2012-01-08 9:35 ` Andreas Schwab
2012-01-08 9:42 ` Alan Hourihane
@ 2012-01-08 10:20 ` Geert Uytterhoeven
2012-01-08 19:21 ` Michael Schmitz
2 siblings, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2012-01-08 10:20 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Alan Hourihane, Linux/m68k
On Sun, Jan 8, 2012 at 05:13, Michael Schmitz <schmitzmic@googlemail.com> wrote:
> 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?
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.
> 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 -- geert@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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-07 1:27 Atari TT (next) Alan Hourihane
2012-01-07 6:47 ` Michael Schmitz
@ 2012-01-08 13:36 ` Andreas Schwab
2012-01-08 14:42 ` Alan Hourihane
2012-01-08 19:24 ` Michael Schmitz
2012-01-08 17:45 ` Geert Uytterhoeven
2 siblings, 2 replies; 43+ messages in thread
From: Andreas Schwab @ 2012-01-08 13:36 UTC (permalink / raw)
To: Alan Hourihane; +Cc: Linux/m68k
Alan Hourihane <alanh@fairlite.co.uk> writes:
> Now the next problem is that the console is all corrupted because atafb
> initializes and shows this...
>
> atafb_init: start
> atafb_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.
screen_base is a virtual address, the physical address is actually
0x146e000.
> 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.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 13:36 ` Andreas Schwab
@ 2012-01-08 14:42 ` Alan Hourihane
2012-01-08 19:24 ` Michael Schmitz
1 sibling, 0 replies; 43+ messages in thread
From: Alan Hourihane @ 2012-01-08 14:42 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Linux/m68k
On 08/01/12 13:36, Andreas Schwab wrote:
> Alan Hourihane <alanh@fairlite.co.uk> writes:
>
>> Now the next problem is that the console is all corrupted because atafb
>> initializes and shows this...
>>
>> atafb_init: start
>> atafb_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.
> screen_base is a virtual address, the physical address is actually
> 0x146e000.
I thought that might be the case, given the TTRAM segment offset. But
still, it's in the wrong area.
>> 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.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-07 1:27 Atari TT (next) Alan Hourihane
2012-01-07 6:47 ` Michael Schmitz
2012-01-08 13:36 ` Andreas Schwab
@ 2012-01-08 17:45 ` Geert Uytterhoeven
2012-01-08 19:50 ` Alan Hourihane
2 siblings, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2012-01-08 17:45 UTC (permalink / raw)
To: Alan Hourihane; +Cc: Linux/m68k
On Sat, Jan 7, 2012 at 02:27, Alan Hourihane <alanh@fairlite.co.uk> wrote:
> 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 -- geert@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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 10:20 ` Geert Uytterhoeven
@ 2012-01-08 19:21 ` Michael Schmitz
2012-01-08 19:53 ` Geert Uytterhoeven
2012-01-08 22:05 ` Andreas Schwab
0 siblings, 2 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-08 19:21 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Alan Hourihane, Linux/m68k
Hi Geert,
>> 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?
>
> 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 ... )
> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 13:36 ` Andreas Schwab
2012-01-08 14:42 ` Alan Hourihane
@ 2012-01-08 19:24 ` Michael Schmitz
1 sibling, 0 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-08 19:24 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Alan Hourihane, Linux/m68k
Hi Andreas,
>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 17:45 ` Geert Uytterhoeven
@ 2012-01-08 19:50 ` Alan Hourihane
0 siblings, 0 replies; 43+ messages in thread
From: Alan Hourihane @ 2012-01-08 19:50 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/m68k
On 08/01/12 17:45, Geert Uytterhoeven wrote:
> On Sat, Jan 7, 2012 at 02:27, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>> 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.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 19:21 ` Michael Schmitz
@ 2012-01-08 19:53 ` Geert Uytterhoeven
2012-01-08 23:42 ` Michael Schmitz
2012-01-08 22:05 ` Andreas Schwab
1 sibling, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2012-01-08 19:53 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Alan Hourihane, Linux/m68k
Hi Michael,
On Sun, Jan 8, 2012 at 20:21, Michael Schmitz <schmitzmic@googlemail.com> wrote:
>>> 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?
>>
>> 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 -- geert@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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 19:21 ` Michael Schmitz
2012-01-08 19:53 ` Geert Uytterhoeven
@ 2012-01-08 22:05 ` Andreas Schwab
2012-01-08 23:39 ` Michael Schmitz
1 sibling, 1 reply; 43+ messages in thread
From: Andreas Schwab @ 2012-01-08 22:05 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Geert Uytterhoeven, Alan Hourihane, Linux/m68k
Michael Schmitz <schmitzmic@googlemail.com> writes:
> 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?
It is a requirement that the kernel is mapped at virtual address zero
since it is not relocatable.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 22:05 ` Andreas Schwab
@ 2012-01-08 23:39 ` Michael Schmitz
2012-01-08 23:49 ` Alan Hourihane
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2012-01-08 23:39 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Geert Uytterhoeven, Alan Hourihane, Linux/m68k
Hi Andreas,
>> 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?
>
> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 19:53 ` Geert Uytterhoeven
@ 2012-01-08 23:42 ` Michael Schmitz
0 siblings, 0 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-08 23:42 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Alan Hourihane, Linux/m68k
Hi Geert,
>>> 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.
> But it's handled completely separately from system RAM.
> Its mapping is set up in mmu_init_amiga() in head.S.
Looks like we may need to do the same for the TT then.
Cheers,
Michael
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 23:39 ` Michael Schmitz
@ 2012-01-08 23:49 ` Alan Hourihane
2012-01-08 23:58 ` Michael Schmitz
0 siblings, 1 reply; 43+ messages in thread
From: Alan Hourihane @ 2012-01-08 23:49 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Andreas Schwab, Geert Uytterhoeven, Linux/m68k
On 08/01/12 23:39, Michael Schmitz wrote:
> Hi Andreas,
>
>>> 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?
>> 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?
>
>From what I can see the first mem_info struct is always mapped at VA 0
which is done in paging_init() in mm/motorola.c
Alan.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 9:42 ` Alan Hourihane
@ 2012-01-08 23:51 ` Michael Schmitz
2012-01-08 23:59 ` Alan Hourihane
2012-01-27 17:01 ` Thorsten Glaser
0 siblings, 2 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-08 23:51 UTC (permalink / raw)
To: Alan Hourihane; +Cc: Linux/m68k, Geert Uytterhoeven
Hi Alan,
>> 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.
>> 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.
>> 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.
> I'll dig in.
Much appreciated.
Michael
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 23:49 ` Alan Hourihane
@ 2012-01-08 23:58 ` Michael Schmitz
0 siblings, 0 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-08 23:58 UTC (permalink / raw)
To: Alan Hourihane; +Cc: Andreas Schwab, Geert Uytterhoeven, Linux/m68k
Hi Alan,
>> 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_info struct is always mapped at VA 0
> which is done in paging_init() in mm/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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 23:51 ` Michael Schmitz
@ 2012-01-08 23:59 ` Alan Hourihane
2012-01-09 0:05 ` Michael Schmitz
2012-01-27 17:01 ` Thorsten Glaser
1 sibling, 1 reply; 43+ messages in thread
From: Alan Hourihane @ 2012-01-08 23:59 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Linux/m68k, Geert Uytterhoeven
On 08/01/12 23:51, Michael Schmitz wrote:
> Hi Alan,
>
>>> 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.
I understand, but the STRAM allocator is broken. It gives out TT-RAM. It
should never do that on a TT.
>>> 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.
>>> 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.
>
>> I'll dig in.
> Much appreciated.
>
No probs. I'll report back when I have something.
Alan.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 23:59 ` Alan Hourihane
@ 2012-01-09 0:05 ` Michael Schmitz
2012-01-09 0:14 ` Alan Hourihane
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-09 0:05 UTC (permalink / raw)
To: Alan Hourihane; +Cc: Linux/m68k, Geert Uytterhoeven
Hi Alan,
> 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.
>> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 0:05 ` Michael Schmitz
@ 2012-01-09 0:14 ` Alan Hourihane
2012-01-09 0:23 ` Andreas Schwab
2012-01-09 1:03 ` Alan Hourihane
2 siblings, 0 replies; 43+ messages in thread
From: Alan Hourihane @ 2012-01-09 0:14 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Linux/m68k, Geert Uytterhoeven
On 09/01/12 00:05, Michael Schmitz wrote:
> Hi Alan,
>
>> 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.
>>> 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.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 0:05 ` Michael Schmitz
2012-01-09 0:14 ` Alan Hourihane
@ 2012-01-09 0:23 ` Andreas Schwab
2012-01-09 3:17 ` Michael Schmitz
2012-01-09 1:03 ` Alan Hourihane
2 siblings, 1 reply; 43+ messages in thread
From: Andreas Schwab @ 2012-01-09 0:23 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Alan Hourihane, Linux/m68k, Geert Uytterhoeven
Michael Schmitz <schmitzmic@googlemail.com> writes:
> Hi Alan,
>
>> 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.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 0:05 ` Michael Schmitz
2012-01-09 0:14 ` Alan Hourihane
2012-01-09 0:23 ` Andreas Schwab
@ 2012-01-09 1:03 ` Alan Hourihane
2012-01-09 1:25 ` Alan Hourihane
2012-01-09 3:16 ` Atari TT (next) Michael Schmitz
2 siblings, 2 replies; 43+ messages in thread
From: Alan Hourihane @ 2012-01-09 1:03 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Linux/m68k, Geert Uytterhoeven
On 09/01/12 00:05, Michael Schmitz wrote:
> 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.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 1:03 ` Alan Hourihane
@ 2012-01-09 1:25 ` Alan Hourihane
2012-01-09 10:40 ` Andreas Schwab
2012-01-09 3:16 ` Atari TT (next) Michael Schmitz
1 sibling, 1 reply; 43+ messages in thread
From: Alan Hourihane @ 2012-01-09 1:25 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Linux/m68k, Geert Uytterhoeven
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: 1024
free_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: 32768
free_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 - 09000000
atari_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: start
atafb_init: initializing TT hw
atari_stram_alloc: allocate 311296 bytes
atari_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 Roman.Hodek@informatik.uni-erlangen.de
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/0x4e
Alan.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 1:03 ` Alan Hourihane
2012-01-09 1:25 ` Alan Hourihane
@ 2012-01-09 3:16 ` Michael Schmitz
1 sibling, 0 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-09 3:16 UTC (permalink / raw)
To: Alan Hourihane; +Cc: Linux/m68k, Geert Uytterhoeven
Hi Alan,
>
> Next problem is the SCSI controller.
My absolute favourite.
> 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.
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 0:23 ` Andreas Schwab
@ 2012-01-09 3:17 ` Michael Schmitz
0 siblings, 0 replies; 43+ messages in thread
From: Michael Schmitz @ 2012-01-09 3:17 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Alan Hourihane, Linux/m68k, Geert Uytterhoeven
Andreas,
On Mon, Jan 9, 2012 at 1:23 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Michael Schmitz <schmitzmic@googlemail.com> writes:
>
>> Hi Alan,
>>
>>> 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.
I stand corrected - we should indeed make it fail by default if no
ST-RAM is available then.
Cheers,
Michael
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 1:25 ` Alan Hourihane
@ 2012-01-09 10:40 ` Andreas Schwab
2012-01-09 11:22 ` Alan Hourihane
2012-01-09 12:14 ` Geert Uytterhoeven
0 siblings, 2 replies; 43+ messages in thread
From: Andreas Schwab @ 2012-01-09 10:40 UTC (permalink / raw)
To: Alan Hourihane; +Cc: Michael Schmitz, Linux/m68k, Geert Uytterhoeven
Alan Hourihane <alanh@fairlite.co.uk> writes:
> *** FORMAT ERROR *** FORMAT=0
> Current process id is 768
> BAD KERNEL TRAP: 00000000
> Modules 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----------------------------------------
>From bbf7451db90fcec5eade9d8bc913b78829192b9c Mon Sep 17 00:00:00 2001
From: Andreas Schwab <schwab@linux-m68k.org>
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(-)
diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
index 1bc223a..aa4ffb8 100644
--- a/arch/m68k/kernel/process_mm.c
+++ b/arch/m68k/kernel/process_mm.c
@@ -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));
}
/*
--
1.7.8.3
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 10:40 ` Andreas Schwab
@ 2012-01-09 11:22 ` Alan Hourihane
2012-01-09 12:14 ` Geert Uytterhoeven
1 sibling, 0 replies; 43+ messages in thread
From: Alan Hourihane @ 2012-01-09 11:22 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Michael Schmitz, Linux/m68k, Geert Uytterhoeven
On 09/01/12 10:40, Andreas Schwab wrote:
> Alan Hourihane <alanh@fairlite.co.uk> writes:
>
>> *** FORMAT ERROR *** FORMAT=0
>> Current process id is 768
>> BAD KERNEL TRAP: 00000000
>> Modules 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.
Great spot!
Seems this also needs massaging into process_no.c too.
But am I at a shell prompt :-)
Alan.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 10:40 ` Andreas Schwab
2012-01-09 11:22 ` Alan Hourihane
@ 2012-01-09 12:14 ` Geert Uytterhoeven
2012-01-09 12:40 ` Tuomas Vainikka
2012-01-09 14:10 ` [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation Andreas Schwab
1 sibling, 2 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2012-01-09 12:14 UTC (permalink / raw)
To: Andreas Schwab, Tuomas Vainikka
Cc: Alan Hourihane, Michael Schmitz, Linux/m68k
On Mon, Jan 9, 2012 at 11:40, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Alan Hourihane <alanh@fairlite.co.uk> writes:
>
>> *** FORMAT ERROR *** FORMAT=0
>> Current process id is 768
>> BAD KERNEL TRAP: 00000000
>> Modules 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----------------------------------------
> From bbf7451db90fcec5eade9d8bc913b78829192b9c Mon Sep 17 00:00:00 2001
> From: Andreas Schwab <schwab@linux-m68k.org>
> 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(-)
>
> diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
> index 1bc223a..aa4ffb8 100644
> --- a/arch/m68k/kernel/process_mm.c
> +++ b/arch/m68k/kernel/process_mm.c
> @@ -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));
> }
>
> /*
> --
> 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 -- geert@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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-09 12:14 ` Geert Uytterhoeven
@ 2012-01-09 12:40 ` Tuomas Vainikka
2012-01-09 14:10 ` [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation Andreas Schwab
1 sibling, 0 replies; 43+ messages in thread
From: Tuomas Vainikka @ 2012-01-09 12:40 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/m68k
On 01/09/2012 02:14 PM, Geert Uytterhoeven wrote:
> On Mon, Jan 9, 2012 at 11:40, Andreas Schwab<schwab@linux-m68k.org> wrote:
>> Alan Hourihane<alanh@fairlite.co.uk> writes:
>>
>>> *** FORMAT ERROR *** FORMAT=0
>>> Current process id is 768
>>> BAD KERNEL TRAP: 00000000
>>> Modules 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----------------------------------------
>> From bbf7451db90fcec5eade9d8bc913b78829192b9c Mon Sep 17 00:00:00 2001
>> From: Andreas Schwab<schwab@linux-m68k.org>
>> 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(-)
>>
>> diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
>> index 1bc223a..aa4ffb8 100644
>> --- a/arch/m68k/kernel/process_mm.c
>> +++ b/arch/m68k/kernel/process_mm.c
>> @@ -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));
>> }
>>
>> /*
>> --
>> 1.7.8.3
> Thanks!
>
> Tuomas: I think this will fix your problem, too?
>
I'll stop nagging if it works. :)
Tuomas
^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation
2012-01-09 12:14 ` Geert Uytterhoeven
2012-01-09 12:40 ` Tuomas Vainikka
@ 2012-01-09 14:10 ` Andreas Schwab
2012-01-22 10:15 ` Geert Uytterhoeven
1 sibling, 1 reply; 43+ messages in thread
From: Andreas Schwab @ 2012-01-09 14:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Tuomas Vainikka, Alan Hourihane, Michael Schmitz, Linux/m68k
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.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
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(-)
diff --git a/arch/m68k/atari/config.c b/arch/m68k/atari/config.c
index 273c7e8..af78731 100644
--- a/arch/m68k/atari/config.c
+++ b/arch/m68k/atari/config.c
@@ -415,9 +415,9 @@ void __init config_atari(void)
* FDC val = 4 -> Supervisor only */
asm volatile ("\n"
" .chip 68030\n"
- " pmove %0@,%/tt1\n"
+ " pmove %0,%/tt1\n"
" .chip 68k"
- : : "a" (&tt1_val));
+ : : "m" (tt1_val));
} else {
asm volatile ("\n"
" .chip 68040\n"
@@ -570,10 +570,10 @@ static void atari_reset(void)
: "d0");
} else
asm volatile ("\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));
}
diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
index 1bc223a..aa4ffb8 100644
--- a/arch/m68k/kernel/process_mm.c
+++ b/arch/m68k/kernel/process_mm.c
@@ -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));
}
/*
diff --git a/arch/m68k/kernel/process_no.c b/arch/m68k/kernel/process_no.c
index 69c1803..5e1078c 100644
--- a/arch/m68k/kernel/process_no.c
+++ b/arch/m68k/kernel/process_no.c
@@ -163,8 +163,8 @@ void flush_thread(void)
#ifdef CONFIG_FPU
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));
#endif
}
diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index 89362f2..eb67469 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -552,13 +552,13 @@ static inline void bus_error030 (struct frame *fp)
#ifdef DEBUG
asm volatile ("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
asm volatile ("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);
asm volatile ("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
- asm volatile ("pmove %%tt0,%0@"
- : /* no outputs */
- : "a" (&tlong));
+ asm volatile ("pmove %%tt0,%0"
+ : "=m" (tlong));
printk("tt0 is %#lx, ", tlong);
- asm volatile ("pmove %%tt1,%0@"
- : /* no outputs */
- : "a" (&tlong));
+ asm volatile ("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
asm volatile ("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
asm volatile ("ptestr #1,%1@,#7\n\t"
- "pmove %%psr,%0@"
- : : "a" (&temp), "a" (addr));
+ "pmove %%psr,%0"
+ : "=m" (temp) : "a" (addr));
#endif
mmusr = temp;
diff --git a/arch/m68k/mm/cache.c b/arch/m68k/mm/cache.c
index 5437fff..5550aa4 100644
--- a/arch/m68k/mm/cache.c
+++ b/arch/m68k/mm/cache.c
@@ -52,9 +52,9 @@ static unsigned long virt_to_phys_slow(unsigned long vaddr)
unsigned long *descaddr;
asm volatile ("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);
--
1.7.8.3
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation
2012-01-09 14:10 ` [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation Andreas Schwab
@ 2012-01-22 10:15 ` Geert Uytterhoeven
2012-01-22 10:53 ` Geert Uytterhoeven
2012-01-22 12:42 ` Andreas Schwab
0 siblings, 2 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2012-01-22 10:15 UTC (permalink / raw)
To: Andreas Schwab
Cc: Tuomas Vainikka, Alan Hourihane, Michael Schmitz, Linux/m68k,
Greg Ungerer
On Mon, Jan 9, 2012 at 15:10, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 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.
> diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
> index 1bc223a..aa4ffb8 100644
> --- a/arch/m68k/kernel/process_mm.c
> +++ b/arch/m68k/kernel/process_mm.c
> @@ -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));
> }
>
> /*
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 -- geert@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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation
2012-01-22 10:15 ` Geert Uytterhoeven
@ 2012-01-22 10:53 ` Geert Uytterhoeven
2012-01-22 12:42 ` Andreas Schwab
1 sibling, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2012-01-22 10:53 UTC (permalink / raw)
To: Andreas Schwab
Cc: Tuomas Vainikka, Alan Hourihane, Michael Schmitz, Linux/m68k,
Greg Ungerer
On Sun, Jan 22, 2012 at 11:15, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Jan 9, 2012 at 15:10, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> 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 -- geert@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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation
2012-01-22 10:15 ` Geert Uytterhoeven
2012-01-22 10:53 ` Geert Uytterhoeven
@ 2012-01-22 12:42 ` Andreas Schwab
1 sibling, 0 replies; 43+ messages in thread
From: Andreas Schwab @ 2012-01-22 12:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Tuomas Vainikka, Alan Hourihane, Michael Schmitz, Linux/m68k,
Greg Ungerer
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> 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.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-08 23:51 ` Michael Schmitz
2012-01-08 23:59 ` Alan Hourihane
@ 2012-01-27 17:01 ` Thorsten Glaser
2012-01-28 20:33 ` Michael Schmitz
1 sibling, 1 reply; 43+ messages in thread
From: Thorsten Glaser @ 2012-01-27 17:01 UTC (permalink / raw)
To: linux-m68k
Michael Schmitz <schmitzmic <at> googlemail.com> writes:
> >> 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.
> 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.
> >> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-27 17:01 ` Thorsten Glaser
@ 2012-01-28 20:33 ` Michael Schmitz
2012-01-29 0:57 ` Thorsten Glaser
0 siblings, 1 reply; 43+ messages in thread
From: Michael Schmitz @ 2012-01-28 20:33 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k
Hi Thorsten,
>>> 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)?
>> 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.
> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-28 20:33 ` Michael Schmitz
@ 2012-01-29 0:57 ` Thorsten Glaser
2012-01-29 9:42 ` Geert Uytterhoeven
0 siblings, 1 reply; 43+ messages in thread
From: Thorsten Glaser @ 2012-01-29 0:57 UTC (permalink / raw)
To: linux-m68k
Michael Schmitz <schmitzmic <at> googlemail.com> writes:
> > 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.
> 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).
> 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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-29 0:57 ` Thorsten Glaser
@ 2012-01-29 9:42 ` Geert Uytterhoeven
2012-01-29 19:55 ` Thorsten Glaser
0 siblings, 1 reply; 43+ messages in thread
From: Geert Uytterhoeven @ 2012-01-29 9:42 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k
On Sun, Jan 29, 2012 at 01:57, Thorsten Glaser <tg@debian.org> wrote:
>> 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 -- geert@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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-29 9:42 ` Geert Uytterhoeven
@ 2012-01-29 19:55 ` Thorsten Glaser
2012-01-29 21:56 ` Geert Uytterhoeven
0 siblings, 1 reply; 43+ messages in thread
From: Thorsten Glaser @ 2012-01-29 19:55 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k
Geert Uytterhoeven dixit:
>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.
>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.
>I really need more time to work on an OpenWRT-based solution ;-)
Or FreeWRT, or OpenADK, or… ;-)
bye,
//mirabilos
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Atari TT (next)
2012-01-29 19:55 ` Thorsten Glaser
@ 2012-01-29 21:56 ` Geert Uytterhoeven
0 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2012-01-29 21:56 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: linux-m68k
On Sun, Jan 29, 2012 at 20:55, Thorsten Glaser <tg@mirbsd.de> wrote:
> Geert Uytterhoeven dixit:
>>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...
>>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 -- geert@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
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2012-01-29 21:56 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-07 1:27 Atari TT (next) Alan Hourihane
2012-01-07 6:47 ` Michael Schmitz
2012-01-07 16:59 ` Alan Hourihane
2012-01-08 0:46 ` Alan Hourihane
2012-01-08 4:13 ` Michael Schmitz
2012-01-08 9:35 ` Andreas Schwab
2012-01-08 9:42 ` Alan Hourihane
2012-01-08 23:51 ` Michael Schmitz
2012-01-08 23:59 ` Alan Hourihane
2012-01-09 0:05 ` Michael Schmitz
2012-01-09 0:14 ` Alan Hourihane
2012-01-09 0:23 ` Andreas Schwab
2012-01-09 3:17 ` Michael Schmitz
2012-01-09 1:03 ` Alan Hourihane
2012-01-09 1:25 ` Alan Hourihane
2012-01-09 10:40 ` Andreas Schwab
2012-01-09 11:22 ` Alan Hourihane
2012-01-09 12:14 ` Geert Uytterhoeven
2012-01-09 12:40 ` Tuomas Vainikka
2012-01-09 14:10 ` [PATCH] m68k: fix assembler constraint to prevent overeager gcc optimisation Andreas Schwab
2012-01-22 10:15 ` Geert Uytterhoeven
2012-01-22 10:53 ` Geert Uytterhoeven
2012-01-22 12:42 ` Andreas Schwab
2012-01-09 3:16 ` Atari TT (next) Michael Schmitz
2012-01-27 17:01 ` Thorsten Glaser
2012-01-28 20:33 ` Michael Schmitz
2012-01-29 0:57 ` Thorsten Glaser
2012-01-29 9:42 ` Geert Uytterhoeven
2012-01-29 19:55 ` Thorsten Glaser
2012-01-29 21:56 ` Geert Uytterhoeven
2012-01-08 10:20 ` Geert Uytterhoeven
2012-01-08 19:21 ` Michael Schmitz
2012-01-08 19:53 ` Geert Uytterhoeven
2012-01-08 23:42 ` Michael Schmitz
2012-01-08 22:05 ` Andreas Schwab
2012-01-08 23:39 ` Michael Schmitz
2012-01-08 23:49 ` Alan Hourihane
2012-01-08 23:58 ` Michael Schmitz
2012-01-08 13:36 ` Andreas Schwab
2012-01-08 14:42 ` Alan Hourihane
2012-01-08 19:24 ` Michael Schmitz
2012-01-08 17:45 ` Geert Uytterhoeven
2012-01-08 19:50 ` Alan Hourihane
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.