; So there are only few MB of RAM freely available for running something
> extra. -> 14MB is indeed minimum to do anything useful.
>
> > >> The installation process is especially memory sensitive, as
> > >> it involves a ramdisk of lots of megs…
> > >
John Paul Adrian Glaubitz dixit:
>Awesome. Let's hope that the FTP team will accept fs-uae into
>unstable soon. Once it's there, it's super easy to update the
You can upload while it’s in NEW. Won’t change much, ofc…
bye,
//mirabilos
--
Ich gebs zu, jupp ist cool
-- theftf zu Naturesha
On 10. okt. 2013 22:36, John Paul Adrian Glaubitz wrote:
> On 10/10/2013 10:30 PM, Geert Uytterhoeven wrote:
> > Nope, Guru 8004, i.e. illegal instruction. So I assume it doesn't
>> support the
>> MMU instructions.
> Ah, right. Same here! Did you check whether it's possible to
> enable the MMU
Frode, thanks a lot for the fast and detailed reply!
On 10/10/2013 10:44 PM, Frode Solheim wrote:
> Hi, improved / full MMU emulation is available in WinUAE 2.6.0 (and
> newer). From the WinUAE 2.6.0 announcement:
> "New features: - Full 68030, 68040 and 68060 MMU emulation. Amix, Linux,
> NetBSD,
On 10/10/2013 10:30 PM, Geert Uytterhoeven wrote:
> Nope, Guru 8004, i.e. illegal instruction. So I assume it doesn't
> support the
> MMU instructions.
Ah, right. Same here! Did you check whether it's possible to
enable the MMU code through the configure script?
@Frode:
Are there any plans
On Thu, Oct 10, 2013 at 10:26 PM, John Paul Adrian Glaubitz
wrote:
> On 10/10/2013 10:23 PM, Geert Uytterhoeven wrote:
>>> OK. I don’t use Windows®, but cbmuser wants to package fs-uae
>>> for Debian which is said to be based on it.
>>
>> I finally exported my A4000 kickstart image from real hardw
On 10/10/2013 10:23 PM, Geert Uytterhoeven wrote:
>> OK. I don’t use Windows®, but cbmuser wants to package fs-uae
>> for Debian which is said to be based on it.
>
> I finally exported my A4000 kickstart image from real hardware to FS-UAE,
> but it seems FS-UAE doesn't have MMU support yet?
fs-ua
On Thu, Jan 24, 2013 at 6:40 PM, Thorsten Glaser wrote:
>>After looking more into this, the Hatari 030 MMU emulation isn't good
>>enough yet for this. But 030 MMU emulation in WinUAE Amiga emulator
>>should now be:
>
> OK. I don’t use Windows®, but cbmuser wants to package fs-uae
> for Debian whi
Hi Geert,
On 05/19/13 10:48, Geert Uytterhoeven wrote:
Hi Alan,
On Sun, Jan 20, 2013 at 8:21 PM, Alan Hourihane wrote:
On 01/20/13 18:22, ragnar wrote:
Am 20.01.2013 18:27, schrieb Alan Hourihane:
I have a patch floating about someplace that corrects this problem. Let
me dig it out.
Yes. P
Hi Alan,
On Sun, Jan 20, 2013 at 8:21 PM, Alan Hourihane wrote:
> On 01/20/13 18:22, ragnar wrote:
>>
>> Am 20.01.2013 18:27, schrieb Alan Hourihane:
>>>
>>> I have a patch floating about someplace that corrects this problem. Let
>>> me dig it out.
>>
>> Yes. Please. Gemini, Mira and i work on th
Hi Thorsten,
> >Does the 'crashing' kernel indeed crash (i.e. the floppy stops blinking)?
>
> AFAIHH it does (did, I disabled the heartbeat LED option now since
> someone complained) *not* stop blinking.
So it's not entirely dead yet. IIRC my old driver crashed the kernel hard so
this may be so
On 01/30/13 08:31, Eero Tamminen wrote:
Hi,
On torstai 24 tammikuu 2013, Eero Tamminen wrote:
So, it seems that it's possible to run just with ST-RAM. I would say
that one needs at least 8MB + swap, or 14MB of RAM.
According to Wikipedia:
http://en.wikipedia.org/wiki/Atari_TT#Technica
Hi,
On torstai 24 tammikuu 2013, Eero Tamminen wrote:
> So, it seems that it's possible to run just with ST-RAM. I would say
> that one needs at least 8MB + swap, or 14MB of RAM.
According to Wikipedia:
http://en.wikipedia.org/wiki/Atari_TT#Technical_specifications
TT machines had 2MB o
schmitz dixit:
> Good one... what was that run from - live CD, or ramdisk?
Hard disc, ext2fs created by FreeMiNT (which uses it natively too).
> We'll see what I get done first - I've got to combine a gazillion commits into
> a few concise ones, doesn't really matter where I start that from.
Go
Thorsten,
Serial output is just nice to capture kernel panic messages. We should get
none of those.
Hehe, speaking of the devil… peek over at gmane.linux.ports.m68k
for one trying to 'busybox mount -o remount,rw /'…
Good one... what was that run from - live CD, or ramdisk?
You'll wan
Michael Schmitz dixit:
>Serial output is just nice to capture kernel panic messages. We should get
>none of those.
Hehe, speaking of the devil… peek over at gmane.linux.ports.m68k
for one trying to 'busybox mount -o remount,rw /'…
>You'll want everything relative to Geert's queue I presume - I'
Thorsten,
> I got told this: “I get messages both on-screen and via serial console.
> I get just the serial output without -s in bootstraps.
> This behaviour is with every kernel I tested so far.”
Good - that's the expected behaviour.
> >Once it's installed and running with network that'll be a
Michael Schmitz dixit:
>Video, in this case.
>
>> gemini8, can you answer this?
I got told this: “I get messages both on-screen and via serial console.
I get just the serial output without -s in bootstraps.
This behaviour is with every kernel I tested so far.”
>> Unsurmountable. But what I mean
Thorsten,
> >Yep - so does the net kernel show any console output with the -s boot flag?
> >If yes, it's a known bug. If not, it's something new and sinister. I'd be
> >surprised if the TT behaved substantially different from the Falcon there.
>
> Console as in, debug=ser, or on the video consol
Michael Schmitz dixit:
>> >use of the -s bootstrap flag, as I've said before. If that works out, we'll
>>
>> The -s flag is required for video output, at the very least, yes.
>
>Yep - so does the net kernel show any console output with the -s boot flag?
>If yes, it's a known bug. If not, it's som
Geert,
> >> The hydra and zorro8390 driver should handle that case fine, as interrupts
> >> are
> >> shared on Amiga.
> >
> > But these will only generate interrupts if the card has something to send,
> > or receive has been enabled. The timer polling seems to be the problem here.
>
> The point
On Thu, Jan 24, 2013 at 9:50 PM, Thorsten Glaser wrote:
> I’m using Geert’s m68k-queue branch plus Alan’s patch.
JFYI that one is rebased on every rc. It's actual source tree is always
identical to master, but it has "clean" commits against Linus' tree, unlike
master.
If you don't want to run rc
On Thu, Jan 24, 2013 at 10:48 PM, Michael Schmitz
wrote:
>> > The ne.c network driver does not appear to tolerate interrupts arriving
>> > before
>> > the device has been configured, at least in the early boot phases. I'm
>> > uncertain
>> > whether it would work even with my latest patches appl
Thorsten,
> >I don't know - I've never checked out that branch. Time to check what's
> >actually in there.
>
> Just in case: my top is 86c0899bb70ee8fa168a7a0711506d616161786e plus
> Alan’s patch (m68k-queue is regularily rebased against torvalds).
I'll look out for that.
> >Looking at the g
Eero Tamminen dixit:
>> That’ll still need a cross toolchain (which is usually not uploaded
>> to Debian itself)
>
>Now that Debian supports multilib, I think it would make a lot of
>sense to have cross-compilers in Debian proper for all the slower
>ports...
It’s Multi-Arch not multilib (which I’
Michael Schmitz dixit:
>> I’m using Geert’s m68k-queue branch plus Alan’s patch.
>> Is that not correct?
>
>I don't know - I've never checked out that branch. Time to check what's
>actually in there.
Just in case: my top is 86c0899bb70ee8fa168a7a0711506d616161786e plus
Alan’s patch (m68k-queue i
Hi,
On perjantai 25 tammikuu 2013, Thorsten Glaser wrote:
> Eero Tamminen dixit:
> >Do you have any idea why EmuTOS (which is GPL v2) isn't packaged
> >for Debian? That would be really nice as then Aranym & Hatari packages
> >could depend from it and work without user needing to download somethin
Thorsten,
> >If the other kernel (nonet) shows a proper boot screen, that's a kernel size
> >issue.
>
> They have very few difference, though.
Just saying. The floppy blink is the only way to tell the kernel is still
running in the absence of screen output (and I've even had cases where the
ker
Eero Tamminen dixit:
>Yes, but the MMU stuff importing from WinUAE to Hatari won't happen
>in time to help getting this stuff working before FOSDEM though. :-)
There’s not enough in place anyway (also, people) to do anything
for FOSDEM – while I’ll be there, I lack hardware, and still don’t
know
Geert,
> > The ne.c network driver does not appear to tolerate interrupts arriving
> > before
> > the device has been configured, at least in the early boot phases. I'm
> > uncertain
> > whether it would work even with my latest patches applied - maybe I can find
> > some time on the weekend to
r though.
> >I would think use of a pre-installed Debian rootfs image to be
> >more appropriate for Atari TT.
>
> Right. I can make these from ARAnyM, now that I have discovered
> its Byte Swap option… wish I had known that at OpenRheinRuhr…
Btw. Latest EmuTOS CVS snapshot
Michael Schmitz dixit:
>If the other kernel (nonet) shows a proper boot screen, that's a kernel size
>issue.
They have very few difference, though.
>That does not include my more recent patches to the interrupt code. I
>suspect you may be using the atari_ethernec driver instead of the generic n
Michael Schmitz dixit:
>can't check what your kernel has built in because it is stripped.
Oh. Hm, of course I only have the vmlinuz file for the !nonet one
left due to an intermediate make clean…
What exactly do you need? The .config is in the image, if it’s
that…
>> >Does the other kernel show
Thorsten,
can't check what your kernel has built in because it is stripped.
> >Does the other kernel show any boot progress on the screen at all, after the
> >bootstrap has finished loading and passed control to the kernel?
>
> Coloured pixels.
Does the 'crashing' kernel indeed crash (i.e. th
On Thu, Jan 24, 2013 at 9:20 PM, Michael Schmitz
wrote:
> The ne.c network driver does not appear to tolerate interrupts arriving before
> the device has been configured, at least in the early boot phases. I'm
> uncertain
> whether it would work even with my latest patches applied - maybe I can f
Thorsten,
> >Does the other kernel show any boot progress on the screen at all, after the
> >bootstrap has finished loading and passed control to the kernel?
>
> Coloured pixels.
If the other kernel (nonet) shows a proper boot screen, that's a kernel size
issue.
On the other hand:
>
> >Can
Michael Schmitz dixit:
>Does the other kernel show any boot progress on the screen at all, after the
>bootstrap has finished loading and passed control to the kernel?
Coloured pixels.
>Can you send me the contents of arch/m68k/atari/config.c and
>arch/m68k/atari/atariints.c from the patched sou
Thorsten,
> >> Hm. Strictly speaking, to verify, we probably need to build a
> >> kernel with*out* those network drivers and test on the TT…
> >
> >Perhaps - but if the serial console log shows it crashes on loading the
> >driver, I'd take the rest for granted.
>
> Can't say about that, but gemi
Michael Schmitz dixit:
>> Hm. Strictly speaking, to verify, we probably need to build a
>> kernel with*out* those network drivers and test on the TT…
>
>Perhaps - but if the serial console log shows it crashes on loading the
>driver, I'd take the rest for granted.
Can't say about that, but gemin
d minimum to do anything useful.
OK. Thanks for the formal (somewhat) analysis.
>I would think use of a pre-installed Debian rootfs image to be
>more appropriate for Atari TT.
Right. I can make these from ARAnyM, now that I have discovered
its Byte Swap option… wish I had known that at Open
re’s none really, but you have a kernel and an initrd,
> and the entire process runs from RAM. Wouter even did build
> d-i images, but they’re not yet usable for various reasons.
I would think use of a pre-installed Debian rootfs image to be
more appropriate for Atari TT.
I remember checking
Hi Thorsten,
> >Has anyone tried the builtin EtherNEC driver on the TT? My attempts to
>
> I think the problem is that it doesn’t *boot* on the TT when
> that driver is compiled in. Those kernels do boot on the Falcon.
So where does it stop (debug=ser2 on a TT IIRC)?
> Hm. Strictly speaking,
Dixi quod…
>Michael Schmitz dixit:
>
>>Has anyone tried the builtin EtherNEC driver on the TT? My attempts to
>
>I think the problem is that it doesn’t *boot* on the TT when
>that driver is compiled in. Those kernels do boot on the Falcon.
>
>Hm. Strictly speaking, to verify, we probably need to b
Michael Schmitz dixit:
>Has anyone tried the builtin EtherNEC driver on the TT? My attempts to
I think the problem is that it doesn’t *boot* on the TT when
that driver is compiled in. Those kernels do boot on the Falcon.
Hm. Strictly speaking, to verify, we probably need to build a
kernel with*o
Hi Thorsten,
> >Agreed - but you're using kernels without support from Debian already. Plus
>
> Only temporarily. And putting together an initrd is a PITA.
Can't speak to the initrd issue - never tried to build cross-initrds.
On 'temporarily' - there'a at least one commit in my network related
Michael Schmitz dixit:
>> But initrds without support from the distros suck, too…
>
>Agreed - but you're using kernels without support from Debian already. Plus
Only temporarily. And putting together an initrd is a PITA.
bye,
//mirabilos
--
„nein: BerliOS und Sourceforge sind Plattformen für Pr
Eero Tamminen dixit:
>I wasn't thinking that Hatari would be used for running the system,
>just help in debugging issues in getting it running.
Right.
>Issues where Hatari can help are unlikely to be dpkg related.
My idea was more to the point of testing the MMU, which
would, I think, involve d
Eero Tamminen dixit:
>> OK, but you should probably direct this to the mailing list.
>> If you want, I can bounce your original mail and this my reply
>> to it, then please reply in positive.
>
>That's ok for me, but I'm not myself subscribed to the list.
No worries, that works with Debian lists,
Hi,
On tiistai 22 tammikuu 2013, Thorsten Glaser wrote:
> Eero Tamminen dixit:
> >I was reading the m68k Debian mailing list archive and noticed
> >your mails about getting Debian/Linux running on TT.
>
> OK, but you should probably direct this to the mailing list.
> If you want, I can bounce you
Eero Tamminen dixit:
>I was reading the m68k Debian mailing list archive and noticed
>your mails about getting Debian/Linux running on TT.
OK, but you should probably direct this to the mailing list.
If you want, I can bounce your original mail and this my reply
to it, then please reply in positi
Hi,
I was reading the m68k Debian mailing list archive and noticed
your mails about getting Debian/Linux running on TT.
Have you considered trying it in the Hatari emulator?
The latest Hatari version in Mercurial repo:
http://hatari.tuxfamily.org/download.html
Has added fixes for 030 MM
On 01/21/13 13:35, Alan Hourihane wrote:
On 01/20/13 20:04, Michael Schmitz wrote:
All,
Attached.
Alan.
Thanks Alan - so vector 112 is VBL, not ST-MFP?
No, it's the VSYNC interrupt on the VME bus.
Oh, sorry, but I guess that's mapped to the VBL interrupt, so yes which
is why we're get
On 01/20/13 20:04, Michael Schmitz wrote:
All,
Attached.
Alan.
Thanks Alan - so vector 112 is VBL, not ST-MFP?
No, it's the VSYNC interrupt on the VME bus.
Alan.
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...
Thorsten,
> >Might be worth a try if the kernel cannot be otherwise shrunk beyond a
> >certain size. I have no idea how much room for modules would be available on
> >a compressed initrd that fits on floppy these days.
>
> But initrds without support from the distros suck, too…
Agreed - but you
Michael Schmitz dixit:
>Might be worth a try if the kernel cannot be otherwise shrunk beyond a
>certain size. I have no idea how much room for modules would be available on
>a compressed initrd that fits on floppy these days.
But initrds without support from the distros suck, too…
bye,
//mirabi
Thorsten,
> >I'll need to clean up the timer D interrupt code regardless. Once the USB
> >code is working for NetUSBee, I guess.
>
> Mhm. Just remember that the networking code (and possibly everything
> related) can’t be modules ;-)
That's a corner case for the TT (or other low memory systems).
Thorsten,
> 1) CONFIG_MODULES=n
> 2) Cannot do that because, without the network, we cannot load
>any modules because that’s where they are…
See my reply to Alan - vector 112 has got nothing to do with MFP.
> >Try swapping this so it looks like such:
>
> I’ll try with Alan’s patch first,
Michael Schmitz dixit:
>I'll need to clean up the timer D interrupt code regardless. Once the USB
>code is working for NetUSBee, I guess.
Mhm. Just remember that the networking code (and possibly everything
related) can’t be modules ;-)
bye,
//mirabilos
--
you introduced a merge commit
All,
> Attached.
>
> Alan.
Thanks Alan - so vector 112 is VBL, not ST-MFP?
I'll need to clean up the timer D interrupt code regardless. Once the USB
code is working for NetUSBee, I guess.
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subjec
Alan Hourihane dixit:
> Attached.
Thanks!
https://www.freewrt.org/~tg/f/vmlinuz-3.8.0-rc4+m68k-queue+atarismall-84660-g49d7bbba
It includes /proc/config.gz support, for Michael and other curious
people. (I repeat, DO NOT take my configs as examples!)
textdata bss dec hex fil
Michael Schmitz dixit:
>Timer D is used by the EtherNEC driver - if thad driver has been compiled in
>please try and load it as a module only.
Two things:
1) CONFIG_MODULES=n
2) Cannot do that because, without the network, we cannot load
any modules because that’s where they are…
>Try swappi
Alan Hourihane dixit:
> On 01/20/13 18:22, ragnar wrote:
>> Am 20.01.2013 18:27, schrieb Alan Hourihane:
>>> I have a patch floating about someplace that corrects this problem. Let
>>> me dig it out.
>> Yes. Please. Gemini, Mira and i work on this.
^
Alan, Thorsten,
> >>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.
Timer D is used by the EtherNEC driver - if thad driver h
On 01/20/13 18:22, ragnar wrote:
Am 20.01.2013 18:27, schrieb Alan Hourihane:
I have a patch floating about someplace that corrects this problem. Let
me dig it out.
Yes. Please. Gemini, Mira and i work on this.
Attached.
Alan.
diff --git a/arch/m68k/atari/ataints.c b/arch/m68k/atari/ataints.
Am 20.01.2013 18:27, schrieb Alan Hourihane:
I have a patch floating about someplace that corrects this problem. Let
me dig it out.
Yes. Please. Gemini, Mira and i work on this.
bye
Bernd
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
On 01/20/13 16:52, Thorsten Glaser wrote:
Geert Uytterhoeven dixit:
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.
That's bad. So most probably i
Geert Uytterhoeven dixit:
>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.
>That's bad. So most probably it's been broken on TT for a long
O.k. I just upgraded the TT-RAM from 128MB to 256MB and now the kernel
crashes with this.
Notice that node_mem_map is for the TT-RAM now.
Any ideas ?
Alan.
Linux version 3.2.0-atari-12913-g35c175f-dirty (root@server) (gc
c version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) ) #43 Tue Jan 1
On Mon, 9 Jan 2012, schmitz wrote:
> Finn,
> > I booted Linux 3.1-rc5 with a BusyBox initramfs on a 4 MB PowerBook
> > recently. I had to create minimal configs for both, but it did indeed
> > boot to a shell prompt.
> >
> Can you provide that ramdisk for this sort of tests? Over on linux-m6
Finn,
I booted Linux 3.1-rc5 with a BusyBox initramfs on a 4 MB PowerBook
recently. I had to create minimal configs for both, but it did indeed boot
to a shell prompt.
Can you provide that ramdisk for this sort of tests? Over on linux-m68k,
Alan has got past the framebuffer problem now, but
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, 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 01/04/12 21:44, Geert Uytterhoeven wrote:
> On Wed, Jan 4, 2012 at 22:38, Alan Hourihane wrote:
>> On 01/04/12 20:53, Petr Stehlik wrote:
>>> Alan Hourihane píše v Wed 04. 01. 2012 v 20:43 +:
>>> The TT has 4MB STRAM and 128MB TT RAM.
>> The kernel, framebuffer, several I/O buffers,
On Wed, Jan 4, 2012 at 22:44, Geert Uytterhoeven wrote:
> On Wed, Jan 4, 2012 at 22:38, Alan Hourihane wrote:
>> On 01/04/12 20:53, Petr Stehlik wrote:
>>> Alan Hourihane píše v Wed 04. 01. 2012 v 20:43 +:
>>> The TT has 4MB STRAM and 128MB TT RAM.
>> The kernel, framebuffer, several
On Wed, Jan 4, 2012 at 22:38, Alan Hourihane wrote:
> On 01/04/12 20:53, Petr Stehlik wrote:
>> Alan Hourihane píše v Wed 04. 01. 2012 v 20:43 +:
>> The TT has 4MB STRAM and 128MB TT RAM.
> The kernel, framebuffer, several I/O buffers, and probably
> the ramdisc and what’s left fro
On 01/04/12 20:53, Petr Stehlik wrote:
> Alan Hourihane píše v Wed 04. 01. 2012 v 20:43 +:
> 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
Alan Hourihane píše v Wed 04. 01. 2012 v 20:43 +:
> >>> 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.
> >>
> >> I can verify that Linu
On 01/04/12 19:57, Alan Hourihane wrote:
> On 01/04/12 19:12, 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 Li
On 01/04/12 19:12, 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.
>
> I can
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.
I can verify that Linux 2.6.39 and 3.0 do NOT boot with only
4 M
Hi all,
I have a copy of Etch for the Atari, but I'm having a whale of a time
trying to find a bootloader that can actually load the kernel.
BOOTSTRA.TOS just silently dies when booting the kernel, and
BOOTATA from Didier either complains about out of memory for ramdisk or
unable to allocate memo
On Wed, Apr 09, 2003 at 08:51:57PM +0200, Björn Buske wrote:
> I built a fresh Kernel 2.4 from CVS using the attached .config file and gcc
> 2.95.4. As before, it wouldn't boot. Following this is the debug-output from
> the serial port. The data read faults just repeat ad inmfinitum.
>
> Hope an
Andreas Schwab schrieb:
>
> Björn Buske <[EMAIL PROTECTED]> writes:
>
> |> > Do you mind giving the 2.4 version from Linux/m68k CVS a try on your TT?
> |>
> |> Love to. Actually, I've been trying to get one built for a while now.
> |> Everything compiles fine, too. Only, when I try to bootstrap t
On Wed, Apr 02, 2003 at 01:43:32PM +0200, Björn Buske wrote:
> I've just started a new clean build with a fresh Source from CVS. If that one
> still won't run, I'll solder up a nullmodem cable and hook it up to the PC.
> Just to be prepared, what RS232-Parameters does the serial console use
> (bau
Björn Buske <[EMAIL PROTECTED]> writes:
|> still won't run, I'll solder up a nullmodem cable and hook it up to the PC.
|> Just to be prepared, what RS232-Parameters does the serial console use
|> (baurdate, handshake, bits) and (most importantly) which port, since the TT
|> has 4 (MFP1, SCC-A, SCC
Andreas Schwab schrieb:
>
> |> > Do you mind giving the 2.4 version from Linux/m68k CVS a try on your TT?
> |>
> |> Love to. Actually, I've been trying to get one built for a while now.
> |> Everything compiles fine, too. Only, when I try to bootstrap the new
> kernel,
> |> the machine totally fr
I installed Woody on my ATARI TT. Does X11 work on it? How do I configure
it? Is there somewhere an instruction? Thank you for any help.
Regards
TScherk, Kiel
98 matches
Mail list logo
