Re: nfhd performance
Geert Uytterhoeven píše v Pá 16. 08. 2013 v 23:57 +0200: In a kernel that has both IDE and nfhd support, once everything is in the buffer cache, I get: atari:~# dd if=/dev/hda2 bs=1M of=/dev/null 141114880 bytes (141 MB) copied, 5.91 seconds, 23.9 MB/s atari:~# dd if=/dev/nfhd8p2 bs=1M of=/dev/null 141114880 bytes (141 MB) copied, 17.09 seconds, 8.3 MB/s FYI, I have just tried running XFERRATE.TTP (freeware by AnodyneSoftware.com) under plain TOS with clock driven by RTC and disk image without byteswap (it's still my original 1000 MB disk from Atari Falcon). I got the following results with a small 30 MB partition that most probably fully fit into host buffer cache: Rwabs() transfer rate: 26660-26220 kb/sec XHDI transfer rate: 26750 kb/sec Please note that the Rwabs is a direct BIOS access. I think it's rather close if not equivalent to your 'dd if=/dev/hda2'. It basically means that since the XHDI path is slightly shorter code path so the data transfer is very slightly faster. That's actually what one could expect. I will try more tests, especially with ByteSwap in ARAnyM enabled (to see if there's a performance penalty). Will also try changing fread to read and implement reading more sectors at once in the XHDI NatFeat implementation. Will post my results here. In summary, the slow nfhd above seems to be caused by the linux-m68k implementation as I can't see such slow down under plain TOS. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nfhd performance
Geert Uytterhoeven píše v Pá 16. 08. 2013 v 23:57 +0200: 141114880 bytes (141 MB) copied, 17.09 seconds, 8.3 MB/s So nfhd is slower than emulated IDE? nfhd is something like IDE with DMA (if everything is in buffer cache then it's doing basically just a memcpy() from cache to the destination place) - can't believe it would be that slow. Don't have profiling numbers at hand but one of the main purposes of nfhd was to be way way faster than the emulated IDE. Something must be seriously wrong somewhere. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make NatFeat drivers bool, not tristate
Geert Uytterhoeven píše v St 24. 07. 2013 v 16:56 +0200: The problem is that aranym expects the parameters of the natfeat calls to be physical addresses. The nf_get_id calls use literal strings as parameters which only works when the drivers are builtin because phys == virt then. And fixing the conversion is non-trivial, as module memory is allocated using vmalloc(), which may be non-contiguous in physical memory space, right? Sounds like the original design decision of NatFeats to use ASCII names instead of cryptic integer codes wasn't that smart. ARAnyM hackers: What's the maximum size of ID names? There isn't any given limit AFAIK, it's based on a common sense when creating a new NatFeat name. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make NatFeat drivers bool, not tristate
Geert Uytterhoeven píše v St 24. 07. 2013 v 18:19 +0200:
On Wed, Jul 24, 2013 at 5:02 PM, Petr Stehlik psteh...@sophics.cz wrote:
ARAnyM hackers: What's the maximum size of ID names?
There isn't any given limit AFAIK, it's based on a common sense when
creating a new NatFeat name.
Understood :-) What's the size of the longest name in use?
aranym/src/natfeat$ grep name\(\) * | grep return
debugprintf.h: const char *name() { return DEBUGPRINTF; }
ethernet.h: const char *name() { return ETHERNET; }
hostfs.h: const char *name() { return HOSTFS; }
nfaudio.h: const char *name() { return AUDIO; }
nf_basicset.h: const char *name() { return NF_NAME; }
nf_basicset.h: const char *name() { return NF_VERSION; }
nf_basicset.h: const char *name() { return NF_SHUTDOWN; }
nf_basicset.h: const char *name() { return NF_STDERR; }
nfbootstrap.h: const char *name() { return BOOTSTRAP; }
nfcdrom.h: const char *name() { return CDROM; }
nfclipbrd.h:const char *name() { return CLIPBRD; }
nfjpeg.h: const char *name() { return JPEG; }
nfosmesa.h: const char *name() { return OSMESA; }
nfpci.h:const char *name() { return PCI; }
nfvdi.h:const char *name() { return fVDI; }
usbhost.h: const char *name() { return USBHOST; }
xhdi.h: const char *name() { return XHDI; }
Is 32 OK?
yes, for now :)
Petr
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new ARAnyM with better FPU
Andreas Schwab píše v Út 27. 03. 2012 v 17:24 +0200: Geert Uytterhoeven ge...@linux-m68k.org writes: aranym_0.9.13-1.lucid.mpfr4_amd64.deb: du fails with memory exhausted, just like in 0.9.9. Stupid portability bug, fixed now. The fix is in aranym_0.9.13-1.1 packages (Debian and Ubuntu): http://sourceforge.net/projects/aranym/files/aranym/0.9.13/ Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ARAnyM 0.9.13 with MPFR even for Lucid
Geert Uytterhoeven píše v St 21. 03. 2012 v 16:08 +0100: On Wed, Mar 21, 2012 at 14:41, Petr Stehlik psteh...@sophics.cz wrote: I am wondering if it is worth backporting the libmpfr and making new ARAnyM packages for 10.04 when the 12.04 is to be released in a month. Indeed, next month we'll all be forced into the new GUI generation... I couldn't stand the feeling that Geert cannot enjoy new Andreas' MPFR FPU emulation in ARAnyM so I have backported the libmpfr4 for Lucid: http://sourceforge.net/projects/aranym/files/aranym/0.9.13/lucid_mpfr4/ And I have also released a new version of ARAnyM that includes another fix that Andreas made two days ago: http://sourceforge.net/projects/aranym/files/aranym/0.9.13/ Enjoy :-) Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new ARAnyM with better FPU
Thorsten Glaser píše v St 21. 03. 2012 v 09:07 +: ARAnyM Debian maintainer is working on updating the package in Debian sid as well. OK, great. I’ll wait for that, upgrade the box with sid on it and will backport to *shudder* hardy Well, beware: Ubuntu 10.10 (including the 10.04 LTS Lucid Lynx) does not have the necessary libmpfr3+. That also means that the Ubuntu Lucid packages I have prepared at http://sourceforge.net/projects/aranym/files/aranym/0.9.12/ do NOT contain the new MPFR based FPU core made by Andreas. So if you really want to try out the new ARAnyM FPU on your Hardy make sure you'll backport libmpfr3+ there first. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new ARAnyM with better FPU
Geert Uytterhoeven píše v Wed 21. 03. 2012 v 11:08 +0100: Well, beware: Ubuntu 10.10 (including the 10.04 LTS Lucid Lynx) does not have the necessary libmpfr3+. That also means that the Ubuntu Lucid packages I have prepared at http://sourceforge.net/projects/aranym/files/aranym/0.9.12/ do NOT contain the new MPFR based FPU core made by Andreas. So if you really want to try out the new ARAnyM FPU on your Hardy make sure you'll backport libmpfr3+ there first. I've just installed the binary for Lucid, and now cp/mv/du from coreutils work again (they failed with out-of-memory errors under Ubuntu's 0.9.9). I guess that was due to the CAS/CAS2 bugs? Most probably. I am wondering if it is worth backporting the libmpfr and making new ARAnyM packages for 10.04 when the 12.04 is to be released in a month. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new ARAnyM with better FPU
Geert Uytterhoeven píše v Wed 21. 03. 2012 v 16:08 +0100: On Wed, Mar 21, 2012 at 14:41, Petr Stehlik psteh...@sophics.cz wrote: I am wondering if it is worth backporting the libmpfr and making new ARAnyM packages for 10.04 when the 12.04 is to be released in a month. Indeed, next month we'll all be forced into the new GUI generation... Actually we won't be forced into that. First, the 10.04 LTS is supported till April next year so people can stay on it for another year. That's why I was wondering whether to backport the libmpfr or not. And second, we have several possibilities of not getting United :-) There's the Classic mode of Gnome Shell that is basically good old Gnome 2 (just rewritten to use newer libraries), then the new Gnome Shell with some particular extensions can be used almost like a normal desktop (Linus and other reported) and at last but not least, the http://cinnamon.linuxmint.com/ is maturing quickly! Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
new ARAnyM with better FPU
Hello there, I think you might be interested in the new ARAnyM release. The version 0.9.12 comes with a brand new FPU emulation core that should be precise because it's using the libmpfr, thanks to Andreas. Andreas also fixed CAS and CAS2 instructions that were behaving incorrectly in some cases. Both these fixes could help running the Linux-m68k kernel and the Debian-68k system more stable on the ARAnyM. I have prepared some binary packages (available for download now) and ARAnyM Debian maintainer is working on updating the package in Debian sid as well. Enjoy, Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] m68k: Update defconfigs
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 capability to ARAnyM's emulated parallel port. Any patches? Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Aranym-dev] [PATCH 0/4] m68k/atari: Add ARAnyM support
Geert Uytterhoeven píše v Ne 06. 02. 2011 v 11:51 +0100: Questions: - Who should be listed as author for patches 1 and 4? initial authors are 1 - Petr Stehlik 4 - Milan Jurik, Petr Stehlik but of course Michael Schmitz a Roman Zippel updated and reworked the ARAnyM support in the linux kernel significantly which should be mentioned somewhere as well. And the network patch was based on Standa Opichal's FreeMiNT driver. - Can I please have Signed-off-by's from the ARAnyM people? Signed-off-by: Petr Stehlik psteh...@sophics.cz Thanks, looking forward to running vanilla linux kernel on ARAnyM :-) Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] m68k/atari: ARAnyM - Add support for console access
Geert Uytterhoeven píše v Ne 06. 02. 2011 v 11:51 +0100: From: Roman Zippel zip...@linux-m68k.org Signed-off-by: Roman Zippel zip...@linux-m68k.org [geert] Cleanups and updates Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org Cc: Petr Stehlik psteh...@sophics.cz Signed-off-by: Petr Stehlik psteh...@sophics.cz Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: debian kernel m68k patches for 2.6.29
Michael Schmitz píše v Čt 16. 04. 2009 v 01:38 +0200: What if I created a disk image with 15, 31, 63, 127, 255 and 511 MB partitions and sent it to you? Would you please list what partition sizes are mountable with _and_ without the Atari FAT patch that we are discussing here? That could finally clear it up (for me at least). I'm happy to do that. Can you please specify what parameters (logical sector size, number of sectors per cluster) the partitions were generated with? Atari GEMDOS and Atari partition programs always use 2 sectors per cluster. Since FAT16 can hold max 32k entries you can compute the rest of information from this (example: 63 MB partition needs 2 kB clusters to fit into 32k cluster limit so the logical sector size for 32-63 MB partition needs to be 1 kB). Yup - did AHDI use particular values for logical sector size and sectors per cluster that we'd need to make sure will still work? See above - 2 logical sectors in a cluster. That is actually the only difference from MS-DOS where they stick with fixed logical sector size and are adding more sectors to a cluster, IIRC. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: debian kernel m68k patches for 2.6.29
Michael Schmitz píše v Čt 16. 04. 2009 v 09:45 +0200: There's something wrong with the Atari FAT option code then - this is what I get with atari=yes on the first of your partitions (128MB?): 255 MB, IIRC (same sector/cluster size as 128 MB) FAT (before atari): FAT bits 0 clusters 32622 sectors 65280 FAT (option atari): FAT bits 12 clusters 32622 sectors 65280 FAT (after atari): FAT bits 12 clusters 32622 sectors 65280 The GEMDOS option code picks a 12 bit FAT even though it should clearly fit into a 16 bit FAT. I don't know what you mean by before/after atari but it's clearly all wrong. FAT12 is on floppies only... Besides that how could 32622 value fit into 12 bit number? Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: debian kernel m68k patches for 2.6.29
Michael Schmitz píše v Út 14. 04. 2009 v 10:26 +0200: At the very least, the default should be changed to atari=off on modern systems like the CT60: Why? How is the CPU accelerator related to disk filesystem? Only in so far as no one would want to use 16 or 32 MB partitions these days. Well, many years ago it used to be suggested to create a smallish boot partition and then larger data/application partition(s). I think the reason for this was that some of the early Atari disk drivers used to loose the first partition's contents occasionally. Anyway, the point is that even these days you can encounter a small partitions on Atari. BTW, does it mean that there is a problem with mounting small GEMDOS partitions in Linux (32 MB?)? And at the same time you can't mount larger partitions because of the logical sector size limit (511 MB)? Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: debian kernel m68k patches for 2.6.29
Michael Schmitz píše v Út 14. 04. 2009 v 09:50 +0200: If someone could provide a disk image to test in ARAnyM, I'd be happy to give it a try. I could create a disk image for testing real quick. Say with 255, 511 and 1023 MB partitions? At the very least, the default should be changed to atari=off on modern systems like the CT60: Why? How is the CPU accelerator related to disk filesystem? Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: debian kernel m68k patches for 2.6.29
Michael Schmitz píše v St 15. 04. 2009 v 03:25 +0200: BTW, does it mean that there is a problem with mounting small GEMDOS partitions in Linux (32 MB?)? And at the same time you can't mount larger partitions because of the logical sector size limit (511 MB)? Small partitions I can mount as regular MSDOS FAT (-o atari=no) only, unless they are 32 MB (in which case it's a 16 bit FAT with few enough clusters to be treated as 16 bit FAT by the Atari FAT patch). I don't think I understand it. What if I created a disk image with 15, 31, 63, 127, 255 and 511 MB partitions and sent it to you? Would you please list what partition sizes are mountable with _and_ without the Atari FAT patch that we are discussing here? That could finally clear it up (for me at least). What disk driver did you create these partitions with? HDDRIVER, so it should be fully AHDI compatible. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] m68k: Add Eiffel PS/2 support for Atari mouse driver
Michael Schmitz píše v Ne 04. 01. 2009 v 22:50 +0100: Note that I have yet to find out whether _releasing_ the middle mouse button on real Eiffel hardware does send the 0x37|0x80 scancode or not. This is unclear from the documentation so I am trying to get a definitive answer from someone who owns the actual hardware. Well, if it sends a different scancode that's easy enough to accomodate. Well I meant that maybe it doesn't send anything. You must be kidding :-) Get to the SETUP somehow (aranym -G -c your_config_file, for example, or use the hotkey) and click the Actually I'm not. The 'pause' hotkey for setup has never worked (neither has any of the various hotkeys for mouse release, BTW). That's why I suggested you to start aranym with -G. Try that and click on the [Hotkeys] dialog to define your own hotkeys. Anyway, still no luck with the ungrab hotkey. See above, it's dead easy to choose your own key. And setting WheelEiffel = Yes did not yield an additional mouse event so far. Try the wheel - it must work even with 0.9.4, I think. The middle mouse is supported in the CVS version only. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] m68k: Fix atarimouse init
Michael Schmitz píše v Ne 04. 01. 2009 v 04:12 +0100: I have added it already. Can you use CVS version of ARAnyM? I've not tried to compile ARAnyM myself in a while, rather installed the latest Debian package as it becomes available. It's a matter of simple ./autogen.sh make but I could create a binary deb for i386 or amd64 if it was of any help (probably not :) Or maybe I could try creating deb-src. You can attach any PS/2 mouse and keyboard to Atari. Seems like this hooks up to the standard keyboard connector so it should behave the same as the regular keyboard/mouse. Good. right Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] m68k: Add Eiffel PS/2 support for Atari mouse driver
Michael Schmitz píše v Ne 04. 01. 2009 v 08:15 +0100: The middle mouse button is mapped to scancode 0x37 (IIRC) while the mouse wheels are provided in IKBD status packet. I've written the first part of the Eiffel PS/2 mouse support, adding middle mouse button support based on the scancode you specified. Implementing the middle mouse button as a toggle is a bit awkward :-( Note that I have yet to find out whether _releasing_ the middle mouse button on real Eiffel hardware does send the 0x37|0x80 scancode or not. This is unclear from the documentation so I am trying to get a definitive answer from someone who owns the actual hardware. I've not tested the code beyond making sure the two regular buttons still work - I do not quite see how to activate Eiffel mouse support in ARAnyM. You must be kidding :-) Get to the SETUP somehow (aranym -G -c your_config_file, for example, or use the hotkey) and click the [ Keyboard + Mouse ] button. The rest (click radio button, click OK, click Save) should be obvious. Or simply edit the aranym config file you use for booting your linux setup, find the [IKBD] section and set the WheelEiffel = Yes. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] m68k: Fix atarimouse init
Andreas Schwab píše v Pá 02. 01. 2009 v 10:42 +0100: Hi Geert, The kernel says (ARAnyM, windowed mode): | Reseting weird mouse packet: 942, 379, 0 | Reseting weird mouse packet: 943, 379, 0 | Reseting weird mouse packet: 945, 378, 0 | Reseting weird mouse packet: 948, 378, 0 | Reseting weird mouse packet: 956, 376, 0 These messages come from ARAnyM. ..and indicates that something wrong is going on. Normally there is only one such message when entering the ARAnyM window. ARAnyM's emulation of the IKBD does not support changing the y origin. will add it there. - the middle mouse button is dead As is expexcted - the original code was for a two-button mouse only. If Petr knows what the ikbd format for the third button is (on real hardware) it's easy to add that in. The IKBD does not support more than two buttons. For a three button mouse the middle button was apparently wired to the joystick port. Yes, that was an old Linux-m68k extension. What I meant by hardware supporting the mouse wheels was Eiffel: http://pagesperso-orange.fr/didierm/eiffel-e.htm In about 3/4 of the long page there is a table labelled Mouse elements that shows the mouse wheels and buttons scan codes. ARAnyM supports the wheels (not sure about the buttons 3,4,5 - will check and add it there eventually). Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] m68k: Fix atarimouse init
Michael Schmitz píše v Pá 02. 01. 2009 v 23:10 +0100: Weird - the inversion of the y direction increment is taken from the old busmouse driver code where it used to work OK. The point of reference is set to be at the top of the 'screen' so moving the mouse down ought to generate positive increments. ARAnyM's emulation of the IKBD does not support changing the y origin. Bummer - any reason the origin was set to the top initially? Isn't it sane to have the origin at top so the mouse increments are logically in sync with video coordinates? I mean I am not sure what's wrong in this chain but I have just tested ARAnyM to ensure that moving the mouse down on the screen generates positive y-axis increments. I guess we could reverse that (at least for ARAnyM). I am against changing generic Atari related things just for ARAnyM. I said earlier (about 12 hours before you posted this mail) that I would fix anything in ARAnyM to make it more linux-m68k compatible. I am just not sure what's wrong here - does the linux-m68k indeed switches the point of origin to bottom of screen and relies on that? Why if you say that the old busmouse code used the normal top-screen origin? How would I go about figuring out the kernel runs on ARAnyM, Petr? Using the NatFeats, of course. But see above - I am against such hacks and I'll add the code for reversing Y-axis real quick if its really necessary. knows what the ikbd format for the third button is (on real hardware) it's easy to add that in. The IKBD does not support more than two buttons. For a three button mouse the middle button was apparently wired to the joystick port. See also http://dev-docs.atariforge.org/files/ikbd_Prot_2-26-1985.pdf. Thanks, Andreas. Seems I'll have to revive the old joystick code, then. Michael, I don't think there is anybody out there using such hardware joystick-mouse modification. But there is number of people using the Eiffel PS/2 adapter so if supporting anything then I'd go for that. BTW, is it just my feeling that you kind of didn't take my mail (Thursday 11:20) into account when replying to Andreas? Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] m68k: Fix atarimouse init
Petr Stehlik píše v So 03. 01. 2009 v 06:53 +0100: Michael Schmitz píše v Pá 02. 01. 2009 v 23:10 +0100: Weird - the inversion of the y direction increment is taken from the old busmouse driver code where it used to work OK. The point of reference is set to be at the top of the 'screen' so moving the mouse down ought to generate positive increments. ARAnyM's emulation of the IKBD does not support changing the y origin. Bummer - any reason the origin was set to the top initially? Isn't it sane to have the origin at top so the mouse increments are logically in sync with video coordinates? BTW, I have just noticed that origin at top = lower left of screen. I was thinking that top would be upper left of screen. Sorry. Anyway, I am just adding the 0x0f/0x10 IKBD opcodes support to ARAnyM. Petr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] atari aranym nfstderr, take 2
Geert Uytterhoeven wrote: The speed doesn't seem to be drastically faster (only twice as fast last I tested with a simple dd). One reason may be that xhdi.cpp opens the file Twice as fast is still better... Speed is not the only advantage - I'd like the possibility of mapping physical host partition directly as an internal disk, without messing with disk images (partitioning them, mounting them on loopback for copying files etc)... Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] atari aranym nfstderr, take 2
Geert Uytterhoeven wrote: BTW, I am amazed by simplicity of the patch and am wondering if it is similarly simple to write a disk driver (to avoid the IDE emulation in ARAnyM). It depends: what interface is available for accessing the virtual disk? Is this the one in xhdi.h? Yes. It closely follows this http://toshyp.atari.org/010008.htm to make writing the disk device driver for FreeMiNT just 1:1 calls mapping. Though only the most important functions are currently implemented: XHReadWrite, XHInqTarget2 and XHGetCapacity. But it can of course be extended in future if there is such need. Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] atari aranym nfstderr, take 2
Geert Uytterhoeven wrote: On Mon, 14 Jan 2008, Michael Schmitz wrote: I've started on that, and run into the issue on what to do with the various minors, i.e. partitions. Other than that, it looks pretty straightforward. Need to check other block drivers for that. Partitions are handled by the generic layer. Just provide `a few' of them. Not sure what you Michael started on but for the [PARTITION] disk driver there is just one partition on each of the disks (=host partitions). Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] atari aranym nfstderr, take 2
Stephen R Marenka píše v So 12. 01. 2008 v 09:55 -0600: Hopefully this patch includes all the of feedback from the last one. This patch adds a character device driver to allow user space access to the aranym natfeats nfstderr. BTW, I am amazed by simplicity of the patch and am wondering if it is similarly simple to write a disk driver (to avoid the IDE emulation in ARAnyM). Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: aranym vs atafb
Michael Schmitz píše v Út 01. 01. 2008 v 04:58 +0100:
Regarding booter options: is there an option to load the kernel to FastRAM
as opposed to ST-RAM, Petr? What is the default here?
ARAnyM LILO doesn't have any options, AFAIK. IMHO the various options of
ataboot (bootstrap) that allow/force loading of either kernel and/or the
ramdisk to ST-RAM/FastRAM exist only because there is a hidden bug
somewhere in the kernel that prevents running it correctly in FastRAM
(the MFP timer goes crazy when its routine is in FastRAM).
In ARAnyM the bug does not manifest itself (mostly because the MFP
emulation is far from correct) so it actually doesn't matter where the
kernel and ramdisks are located. BTW, looking into
aranym/src/bootos_linux.cpp it seems that FastRAM is preferred for the
ramdisk:
/*--- Copy the ramdisk after kernel (and reserved bootinfo) ---*/
if (ramdisk ramdisk_length) {
unsigned long rd_start;
unsigned long rd_len;
rd_len = ramdisk_length - RAMDISK_FS_START;
if (FastRAMSizerd_len) {
/* Load in FastRAM */
rd_start = FastRAMBase;
memcpy(FastRAMBaseHost, ((unsigned char *)ramdisk) +
RAMDISK_FS_START,
rd_len);
} else {
/* Load in ST-RAM */
rd_start = RAMSize - rd_len;
memcpy(RAMBaseHost+rd_start, ((unsigned char *)ramdisk) +
RAMDISK_FS_START, rd_len);
}
You could play with the ataboot if you want to load the kernel and
ramdisk to certain type of memory (if you have the latest version - I
remember fixing the loading there).
As to your question regarding the most generic fix: if there really is not
enough ST-RAM (i.e. the available space is taken by the kernel and the
ramdisk, after 'unpacking' the ramdisk to the buffer cache) we'd need to
either make the ramdisk unpack go to non-DMA memory (no idea here;
ideally the buffer cache should not have a preference for DMA memory in
this case), or reserve a chunk of memory up front (tried that in a hackish
way).
Well, I was asking how to properly flag the type of memory, not how to
manage the loading and upacking. IMHO if the size and location of memory
is passed to kernel from the bootstrap then also the bootstrap should
tell the kernel which memory is of which type.
As for the loading and unpacking itself - the ST-RAM is 10x slower than
FastRAM (on a real machine) so it shouldn't be used at all. It should be
arranged somehow so that the ST-RAM is kind of last-resort, something
like a slightly faster disk swap.
Petr
-
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/68] 0 - NULL, for arch/m68k
Yoann Padioleau wrote: When comparing a pointer, it's clearer to compare it to NULL than to 0. stram_start = phys_to_virt(0); - kernel_in_stram = (stram_start == 0); + kernel_in_stram = (stram_start == NULL); stram_start is more like an offset than pointer, IMHO. And 0 is a valid offset. The ==NULL does not make much sense in this particular case. NULL is usually used when checking for an uninitialized pointer, right? Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.6.19 m68k Atari: ARAnyM support
Geert Uytterhoeven píše v Út 12. 12. 2006 v 21:46 +0100:
Should be signed off by Petr, really.
I am OK with it so long as it works :-)
+static struct nf_ops _nf_ops = { nf_get_id_instr, nf_call_instr };
^^
Ugh, nice compiler warnings. What about using correct C prototypes with inline
assembler instead of these hardcoded unsigned longs?
Feel free to rewrite it, really.
Petr
-
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.6.19 m68k Atari: ARAnyM support
Roman Zippel wrote: While looking over this, I'm playing with the idea to move this to its own directory. This stuff is rather generic and it seems the API is intended to be used by various emulators. that is correct. It may also be possible at some point to have a kernel without Atari support and just use the emulator API to communicate with the outside world. This is also correct. We can access graphics, sound and disk directly via the NatFeats. What remains is keyboard/mouse input - then we would not use any Atari specific HW (well apart from the MFP interrupts which are tied to CPU closely, anyway). Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6 kernel on aranym?
Kolbjørn Barmen wrote: Just curious.. have anyone done this? Michael did, I believe. Perhaps he could make a binary of the kernel (best with the aranym patches) available somewhere. Also, with the 2.4.27 kernel I did not get the tap/tun working I'd like to prepare some ipmasq and bridge-utils scripts when I get some time. Until then follow the wiki with the iptables, arp-proxy or run the arabridge script if you're in a LAN. BTW, I have just realized that the chmod u+s /usr/bin/aratapif is still missing in the deb package. to find a way to access the ext2 partitions on the disk image directly from outside aranym. I suspect I might be able to do this using losetup with an offset argument, but I have not managed it yet. Anyone have a tip? losetup should work but I haven't tried. Please add your experience to http://wiki.aranym.org/ , thanks. Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.4.30: Atari EtherNEC driver Mark II
Michael Schmitz píše v Út 14. 11. 2006 v 17:53 +0100: Hi, some NE2000 clones apparently are not detected by the old driver, so here's my second stab at it. The receive overrun messages have also been shut up. just got it running in a self-compiled 2.4.27. It works! I am so excited having Sarge fresh netinstall working. It's amazing to see linux on my Falcon running again. Thanks to everyone who made this possible. Now we just need to fix the partitioner in d-i to allow out of the box installation on Atari. With the ethernec support in Debian etch many people could see the power of Debian GNU/Linux on their atari computers. Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FPU emulation
Michael Schmitz píše v Pá 17. 11. 2006 v 10:31 +0100: Kernel FPU emulation just means there is a F-line trap handler available. That trap should also work on context switching, unless I'm mistaken. I put the question wrongly. I wanted to ask if it is possible to run linux plus its applications on 68RC040 like if it was 68LC040 (i.e. without ever touching FPU registers and calling FPU instructions). The reason for such weird question is that I identified FPU emulation bug in ARAnyM and I thought I could compare it with running on native m68k FPU emulation in the kernel. Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FPU emulation
Petr Stehlik píše v Pá 17. 11. 2006 v 12:54 +0100: Michael Schmitz píše v Pá 17. 11. 2006 v 10:31 +0100: Kernel FPU emulation just means there is a F-line trap handler available. That trap should also work on context switching, unless I'm mistaken. I put the question wrongly. I wanted to ask if it is possible to run linux plus its applications on 68RC040 like if it was 68LC040 (i.e. without ever touching FPU registers and calling FPU instructions). I just realized that FPU detection is done not only in kernel but also probably in libc (for each application) so this is not kernel related question. Easiest would be to disable the FPU emulation in aranym, eventual kernel modifications wouldn't help here. Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Networking for ARAnyM
Christian T. Steigies píše v Po 22. 08. 2005 v 22:34 +0200: On Sun, Aug 21, 2005 at 02:59:45AM +0200, Petr Stehlik wrote: I have just got the NF based ethernet driver for linux-m68k working. I have to create a new kernel-patch-2.4.27-m68k package, since the old one does not apply cleanly anymore to the new kernel-source in unstable. Do you want me to include this patch in the -patch package? The README says with this patch a real Atari will not work anymore, so I would not enable it. I have just released a new tarball at http://web.zln.cz/~joy/linux-natfeats.tar.gz Spent two days just by cleaning up the source code. I doubt I can get it any better so here it is. New config entries (ARANYM and ATARI_NFETH). Separated NatFeat API. Documented including help in make config. And best of all - this kernel has been tested on real hardware and worked well so the ARAnyM support (or generally the NatFeats in the kernel) can be safely enabled by default! Now I would be real glad if this got included in the kernel-m68k package. Together with new ARAnyM (soon to be released and uploaded to Debian) it could allow anyone to test the net-install on m68k ;-) Thanks. Petr P.S. I welcome any kernel hacker's critical review of my patches. They work but might not be ideal or even good enough. P.P.S. Another good news is that I managed to fix my Falcon/AB40 machine so I will be able to test the new 2.6.x kernels including the Mach64 patch that has been posted to kernel ML recently. - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: to cross-compile 2.6.x with old binutils
Geert Uytterhoeven píše v So 06. 08. 2005 v 22:26 +0200: Attached is the one from 2.6.13-rc5 using atari_defconfig. I expect it to work with 2.6.8, too. If it doesn't, please let me know. Thanks a lot, it allowed me to compile 2.6.8 kernel for atari. However it doesn't run for too long: Linux version 2.6.8 ([EMAIL PROTECTED]) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #2 Sat Aug 6 23:47:01 CEST 2005 Atari hardware found: VIDEL STDMA-SCSI ST_MFP STND_DMA YM2149 PCM CODEC DSP56K ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED initrd: 00e0 - 0128b800 Built 1 zonelists Kernel command line: root=/dev/ram load_ramdisk=1 ramdisk_size=2 stram_swap=0 debug debug=par video=atafb:vga16 debian-installer/framebuffer=false BOOT_IMAGE=vmlinux PID hash table entries: 16 (order 4: 128 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) *** ILLEGAL INSTRUCTION *** FORMAT=0 Current process id is 0 BAD KERNEL TRAP: Modules linked in: PC: [0002c0ea] free_pages_bulk+0x110/0x198 SR: 2700 SP: 001cdee0 a2: 001542f6 d0: 0001d1: 4e00d2: 3c01d3: d4: 1e00d5: a0: 0001a1: 0002 Process swapper (pid: 0, stackpage=001552f6) Stack from 001cdee0: 4e00 3c01 1e00 0001 0002 001542f6 0001 2702 c0ea0010 2304 0008 5000 44d5 002942ac 00157b24 00157a40 001cdff8 0001 0001 00157a94 2700 0002c44c 00157a40 0003 00157b34 4e13 002942ac 001ab6b8 001d4000 0002c47c 002942ac 0002c8d0 002942ac 001c0d7a 002942ac 000c Call Trace: [0001861a] printk+0x0/0xee [001c0eda] free_all_bootmem+0xa/0x10 [001be7c8] mem_init+0x2c/0x118 [0001861a] printk+0x0/0xee [001bbeb0] start_kernel+0x11e/0x1b0 [001bb31e] __start+0x31e/0x9c4 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing Although this might be a problem in aranym, I'll try it on a real atari asap. Petr - To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
