Alan Hourihane writes:
> Could these spurious interrupts be generated by the debug path, because
> I'm now using it to output debug data ?
None of the debug devices are touching tt_mfp (ser2 uses the SCC, and
ser1 uses st_mfp).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerp
On Thu, Jan 5, 2012 at 20:02, Alan Hourihane wrote:
>>> unexpected interrupt from 112
>> That's the vector number, so the actual IRQ number is 112 / 4 = 28, which is
>> IRQ_TT_MFP_TIMD. Sorry, no clues.
>>
>> Can you please try a pristine v3.1? The only relevant differences are the
>> conversion t
On 05/01/12 15:49, Andreas Schwab wrote:
> Geert Uytterhoeven writes:
>
>> On Thu, Jan 5, 2012 at 13:55, Alan Hourihane wrote:
>>> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
>> bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
>> BROKEN, so you
On 05/01/12 14:42, Geert Uytterhoeven wrote:
> On Thu, Jan 5, 2012 at 13:55, Alan Hourihane wrote:
>> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
> bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
> BROKEN, so you cannot select it.
> If you rever
On 05/01/12 14:42, Geert Uytterhoeven wrote:
> On Thu, Jan 5, 2012 at 13:55, Alan Hourihane wrote:
>> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
> bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
> BROKEN, so you cannot select it.
> If you rever
Geert Uytterhoeven writes:
> On Thu, Jan 5, 2012 at 13:55, Alan Hourihane wrote:
>> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
>
> bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
> BROKEN, so you cannot select it.
> If you revert 173808aa9203
On Thu, Jan 5, 2012 at 13:55, Alan Hourihane wrote:
> Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
bff0dc7 = m68k-v3.1. That kernel still has the SCC driver, but it depends on
BROKEN, so you cannot select it.
If you revert 173808aa9203cf752518acd80fde3c9c910ddd0f ("m68k/ata
Thanks again Geert for the debug pointer.
With that I'm getting this.
Linux version 3.1.0-atari-00246-gbff0dc7 (root@server) (gcc version
4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #2 Thu Jan 5 09:41:26 GMT 2012
console [debug0] enabled
Atari hardware found: TT_SHIFTER ST_MFP TT_MFP TT_SCSI_DM
On 01/05/12 12:39, Geert Uytterhoeven wrote:
> On Thu, Jan 5, 2012 at 13:15, Alan Hourihane wrote:
>> But we now know that STRAM isn't the issue. The bootloader can handle
>> loading this into FASTRAM.
>>
>> Just vertical lines and no serial console has stalled me. So I'm messing
>> with the git t
On Thu, Jan 5, 2012 at 13:15, Alan Hourihane wrote:
> But we now know that STRAM isn't the issue. The bootloader can handle
> loading this into FASTRAM.
>
> Just vertical lines and no serial console has stalled me. So I'm messing
> with the git trees to get back to some sane atari_scc.c code.
deb
On 01/05/12 10:44, Finn Thain wrote:
> On Wed, 4 Jan 2012, Thorsten Glaser wrote:
>
>> Alan Hourihane dixit:
>>
>>> The TT has 4MB STRAM and 128MB TT RAM.
>> ^
>>
>> The kernel, framebuffer, several I/O buffers, and probably
>> the ramdisc and what?s left from TOS/GEM before Lin
Finn Thain dixit:
>recently. I had to create minimal configs for both, but it did indeed boot
Debian isn’t exactly that. (The kernel needs to support quite
some hardware out of the box, and the initrd is not just
busybox…)
bye,
//mirabilos
--
On Wed, 4 Jan 2012, Geert Uytterhoeven wrote:
> Findings:
> - CONFIG_BLK_DEV_SWIM is m, while CONFIG_AMIGA_FLOPPY and
> CONFIG_ATARI_FLOPPY are y.
My defconfig patch used "m" because (if I recall correctly) the SWIM
driver is experimental code that couldn't be safely loaded on all
machin
On Wed, 4 Jan 2012, Thorsten Glaser wrote:
> Alan Hourihane dixit:
>
> >The TT has 4MB STRAM and 128MB TT RAM.
> ^
>
> The kernel, framebuffer, several I/O buffers, and probably
> the ramdisc and what?s left from TOS/GEM before Linux takes
> over all has to fit into it.
>
>
On Thu, 5 Jan 2012, Geert Uytterhoeven wrote:
> Finn, Michael: as pmaczilog uses platform devices, it can be made to
> work on Atari, too?
I would think so. I don't recall anything peculiar about the platform
device variant though the overlapping MMIO address ranges in the platform
resources
Thorsten Glaser píše v St 04. 01. 2012 v 22:22 +:
> This is something I'd like to see, if it is possible from
> the hardware: ARAnym’s emulated parallel port for debugging
> is unidirectional (printing only), so, in headless mode,
> you get no console at all
I'll gladly add bidirectional capab
On Thu, Jan 5, 2012 at 10:58, Alan Hourihane wrote:
> It would certainly be wonderful to have atari_scc.c back.
You can probably just "git revert" the relevant commits to resurrect all pieces
and make it work again for debugging. But the result won't go upstream.
Gr{oetje,eeting}s,
On 01/05/12 09:52, Geert Uytterhoeven wrote:
> On Wed, Jan 4, 2012 at 23:22, Thorsten Glaser wrote:
>> Geert Uytterhoeven dixit:
>>
>>>CONFIG_SERIAL_CONSOLE: y . . . . . . . . . . y
>> This is something I'd like to see, if it is possible from
>> the hardware: ARAnym’s emulated
On Wed, Jan 4, 2012 at 23:22, Thorsten Glaser wrote:
> Geert Uytterhoeven dixit:
>
>> CONFIG_SERIAL_CONSOLE : y . . . . . . . . . . y
>
> This is something I'd like to see, if it is possible from
> the hardware: ARAnym’s emulated parallel port for debugging
> is unidirectional (p
19 matches
Mail list logo
