freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] [Freemint-list] Broken udelay() for m68000

[Miro K. <mir...@gm...>]

Hi David,

if the interpretation you've mentioned in https://github.com/
freemint/freemint/issues/70 holds for all drivers (i.e. that the delay is
supposed to wait *at least* X microseconds) there shouldn't be any
regressions IMHO -- the new formula must definitely take longer than the
previous stub.

As for your question
<https://github.com/freemint/freemint/issues/70#issuecomment-366506935> about
"__M68020__": gcc 7.2 emits them only for -m68020-40 and -m68020-60 (no,
not even -m68020!). It definitely seems like some kind of deprecated macro
kept only for the minimal backward compatibility.

On 19 February 2018 at 02:32, David Gálvez <dga...@gm...> wrote:

> Yesterday I sent the email below to the list address at atari-forge, I
> didn't watch that the email I was answering was sent to the the old
> list address.
> Today it bounced so I send it again to the right address.
>
> 2018-02-17 10:04 GMT+01:00 David Gálvez <dga...@gm...>:
> > 2017-10-16 3:57 GMT+02:00 Miro Kropáček <mir...@gm...>:
> >> After some study, it seems it isn't that bad (I think most of you were
> aware
> >> of it): the delay functions are calibrated, quite precisely actually.
> That
> >> loops_per_sec variable is actually a result of such calibration.
> >>
> >> So the problem is that m68000 code ignores it. I think David is right,
> the
> >> magic formula used in the linux kernel is supposed to work on all
> m68ks, not
> >> only ColdFire (see the comment, "simpler m68k").
> >>
> >> On m68000, the code is quite chatty:
> >>
> >>      3a4:       206a 001c       moveal %a2@(28),%a0
> >>      3a8:       4878 00c8       pea c8 <oldSR-0x1c>
> >>      3ac:       2f10            movel %a0@,%sp@-
> >>      3ae:       4e93            jsr %a3@
> >>      3b0:       508f            addql #8,%sp
> >>      3b2:       720b            moveq #11,%d1
> >>      3b4:       e2a8            lsrl %d1,%d0
> >>      3b6:       2200            movel %d0,%d1
> >>      3b8:       d280            addl %d0,%d1
> >>      3ba:       d280            addl %d0,%d1
> >>      3bc:       2801            movel %d1,%d4
> >>      3be:       e98c            lsll #4,%d4
> >>      3c0:       d284            addl %d4,%d1
> >>      3c2:       2801            movel %d1,%d4
> >>      3c4:       e18c            lsll #8,%d4
> >>      3c6:       d284            addl %d4,%d1
> >>      3c8:       e789            lsll #3,%d1
> >>      3ca:       d081            addl %d1,%d0
> >>      3cc:       ec88            lsrl #6,%d0
> >>
> >> (a3 points to ___udivsi3)
> >>
> >> However we should use this code also for 68060 and not only for CF as
> mul
> >> ea,dr:dq is not implemented on 060 (leading to a huge performance
> bottleneck
> >> I imagine).
> >>
> >
> > I've just pushed a commit to make 68000 builds to use "real" delays
> > and fix this situation.
> >
> > Some drivers that were adjusted to the old delay method could break,
> > For what I could see they're usb.km, storage.udd and asix.xif or the
> > TOS variant of them (only 68000 builds).
> > I've asked in AF for testers but I didn't get too much feedback, I
> > decided to push anyway I don't want the commits to end dying in my
> > hard drive as already has happened to me in the past.
> > If you read users complaining about these drivers malfunction with
> > recent kernel versions keep in mind this commit could be a reason.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] [Freemint-list] Broken udelay() for m68000

[David G. <dga...@gm...>]

Yesterday I sent the email below to the list address at atari-forge, I
didn't watch that the email I was answering was sent to the the old
list address.
Today it bounced so I send it again to the right address.

2018-02-17 10:04 GMT+01:00 David Gálvez <dga...@gm...>:
> 2017-10-16 3:57 GMT+02:00 Miro Kropáček <mir...@gm...>:
>> After some study, it seems it isn't that bad (I think most of you were aware
>> of it): the delay functions are calibrated, quite precisely actually. That
>> loops_per_sec variable is actually a result of such calibration.
>>
>> So the problem is that m68000 code ignores it. I think David is right, the
>> magic formula used in the linux kernel is supposed to work on all m68ks, not
>> only ColdFire (see the comment, "simpler m68k").
>>
>> On m68000, the code is quite chatty:
>>
>>      3a4:       206a 001c       moveal %a2@(28),%a0
>>      3a8:       4878 00c8       pea c8 <oldSR-0x1c>
>>      3ac:       2f10            movel %a0@,%sp@-
>>      3ae:       4e93            jsr %a3@
>>      3b0:       508f            addql #8,%sp
>>      3b2:       720b            moveq #11,%d1
>>      3b4:       e2a8            lsrl %d1,%d0
>>      3b6:       2200            movel %d0,%d1
>>      3b8:       d280            addl %d0,%d1
>>      3ba:       d280            addl %d0,%d1
>>      3bc:       2801            movel %d1,%d4
>>      3be:       e98c            lsll #4,%d4
>>      3c0:       d284            addl %d4,%d1
>>      3c2:       2801            movel %d1,%d4
>>      3c4:       e18c            lsll #8,%d4
>>      3c6:       d284            addl %d4,%d1
>>      3c8:       e789            lsll #3,%d1
>>      3ca:       d081            addl %d1,%d0
>>      3cc:       ec88            lsrl #6,%d0
>>
>> (a3 points to ___udivsi3)
>>
>> However we should use this code also for 68060 and not only for CF as mul
>> ea,dr:dq is not implemented on 060 (leading to a huge performance bottleneck
>> I imagine).
>>
>
> I've just pushed a commit to make 68000 builds to use "real" delays
> and fix this situation.
>
> Some drivers that were adjusted to the old delay method could break,
> For what I could see they're usb.km, storage.udd and asix.xif or the
> TOS variant of them (only 68000 builds).
> I've asked in AF for testers but I didn't get too much feedback, I
> decided to push anyway I don't want the commits to end dying in my
> hard drive as already has happened to me in the past.
> If you read users complaining about these drivers malfunction with
> recent kernel versions keep in mind this commit could be a reason.

Re: [Freemint-discuss] $Id$ CVS keyword

[David G. <dga...@gm...>]

Done!

2018-02-16 9:51 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Hi David,
>
>> If nobody has any objection I'm going to delete them.
>
> I have been thinking about the same for some months. I think there's no
> benefit in those ids, so go ahead.
>
> --
> MiKRO / Mystic Bytes
> http://mikro.atari.org

[Freemint-discuss] Chroot Troubles

[Mark D. <mdu...@at...>]

Hello all,

Once upon a time I was told that chroot in mint works fine.  I decided
to try it and on the surface it looks good but when I dig deeper there
is issues.  Here it is demonstrated.  Current kernel, coreutils chroot
binary.

Create a bootstrap under /root/bootstrap  Not much under there, just
coreutils, rpm and a few other things.

root@bf3:/root>chroot /root/bootstrap /bin/bash
bash-2.05a# pwd
/e/root/bootstrap
bash-2.05a# ls
bin  etc  sbin  usr  var
bash-2.05a#

Ok so bash doesn't find anything which means bash is respecting the
chroot.  We did change directories but pwd can see it is not in a new root.

bash-2.05a# ls
bin  etc  sbin  usr  var
bash-2.05a# pwd
/
bash-2.05a#

Ok but we can go to / and the chroot is adhered to.  Maybe we can
proceed.  What is under /var

bash-2.05a# ls
adm  catman  log
bash-2.05a#

Ok so proceed.

bash-2.05a# rpm -qa
automake-1.11.1-1 
info-4.0-2             
cpio-2.4.2-3      
procps-ng-3.3.2-1    
bzip2-1.0.2-1

....

and so on.  The rpm database is the one from outside the chroot.  Any ideas?

Thanks,

Mark

[Freemint-discuss] TOSWIN colours

[Peter S. <p....@sc...>]

Is there any way to make the toswin2 shell to display diffent colours
for files and directories like the shell in linux ?

Peter

Re: [Freemint-discuss] Mint update 976

[Peter S. <p....@sc...>]

The errors look like they are happening as it processes /etc/fstab

They look like

nfs_root(nn) -> ENXIO

followed by a warning about mounting unchecked filesystem.



Regards,



On Fri, 16 Feb 2018 19:06:38 , Peter Slegg <p....@sc...> wrote:
>
> It's difficult because the errors are not logged anywere.
> Is there an AUTO prog that can capture all the boot mesages ?
>
> The messages are for all the partitions of all types (FATFS, NFS) and
> the error says either EXNIO or EXIO. Something like that.
> It's not on screen for very long.
>
> In most cases the file check doesn't actually need to examine the
> partitions so there is not progress bar. When it did need to run it
> ran ok.
>
>
> Peter
>
>
>
>
>
> On Fri, 16 Feb 2018 20:37:55 , Miro Kropá?ek wrote:
> > Hi,
> >
> >
> > > During boot it is giving an error for each partition saying that
> > > it is mounting an unchecked filesystem.
> > >
> > > # Filesystemcheck (mandatory)
> > > exec u:\c\mint\bin\sh u:\c\mint\bin\fscheck.sh
> > >
> > > I have the check in mint.cnf so I am a investigating what is going wrong.
> > >
> >
> > you should be a bit more specific if you expect some feedback. Like:
> >
> > - what kind of partitions
> > - does the check finish and if so, does it the check happen again?
> > - do you see the progress bar (
> > https://github.com/freemint/freemint/issues/73)
> >
> > And while you're at it, whether you see any improvement in your
> > https://github.com/freemint/freemint/issues/62 :)
> >
>
>

[Freemint-discuss] (no subject)

    <p....@sc...>
Cc: <fre...@li...>
From: Peter Slegg <p....@sc...>
Subject: Re: [Freemint-discuss] Mint update 976
Reply-To: Peter Slegg <p....@sc...>
X-Mailer: MyMAIL Rev:1.96.04.14145 (Atari/(STiK/STinG/GlueSTiK))
X-Hardware: Atari Milan
MIME-Version: 1.0
Date: Fri, 16 Feb 2018 19:06:38 +0000 (GMT)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <000...@sm...>
References: <CAN5rfbShyxVEUL+z+520kQkk-=_Rw...@ma...>
In-Reply-To: CAN5rfbShyxVEUL+z+520kQkk-=_Rw...@ma...


It's difficult because the errors are not logged anywere.
Is there an AUTO prog that can capture all the boot mesages ?

The messages are for all the partitions of all types (FATFS, NFS) and
the error says either EXNIO or EXIO. Something like that.
It's not on screen for very long.

In most cases the file check doesn't actually need to examine the
partitions so there is not progress bar. When it did need to run it
ran ok.


Peter





On Fri, 16 Feb 2018 20:37:55 , Miro Krop=E1?ek wrote:
> Hi,
>
>
> > During boot it is giving an error for each partition saying that
> > it is mounting an unchecked filesystem.
> >
> > # Filesystemcheck (mandatory)
> > exec u:\c\mint\bin\sh u:\c\mint\bin\fscheck.sh
> >
> > I have the check in mint.cnf so I am a investigating what is going wrong.
> >
>
> you should be a bit more specific if you expect some feedback. Like:
>
> - what kind of partitions
> - does the check finish and if so, does it the check happen again?
> - do you see the progress bar (
> https://github.com/freemint/freemint/issues/73)
>
> And while you're at it, whether you see any improvement in your
> https://github.com/freemint/freemint/issues/62 :)
>

Re: [Freemint-discuss] Mint update 976

[Miro K. <mir...@gm...>]

Hi,


> During boot it is giving an error for each partition saying that
> it is mounting an unchecked filesystem.
>
> # Filesystemcheck (mandatory)
> exec u:\c\mint\bin\sh u:\c\mint\bin\fscheck.sh
>
> I have the check in mint.cnf so I am a investigating what is going wrong.
>

you should be a bit more specific if you expect some feedback. Like:

- what kind of partitions
- does the check finish and if so, does it the check happen again?
- do you see the progress bar (
https://github.com/freemint/freemint/issues/73)

And while you're at it, whether you see any improvement in your
https://github.com/freemint/freemint/issues/62 :)

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] Mint update 976

[Peter S. <p....@sc...>]

Hi,

I've just updated for the first time since last September.

During boot it is giving an error for each partition saying that
it is mounting an unchecked filesystem.

# Filesystemcheck (mandatory)
exec u:\c\mint\bin\sh u:\c\mint\bin\fscheck.sh

I have the check in mint.cnf so I am a investigating what is going wrong.


Peter

Re: [Freemint-discuss] $Id$ CVS keyword

[Miro K. <mir...@gm...>]

Hi David,

If nobody has any objection I'm going to delete them.
>
I have been thinking about the same for some months. I think there's no
benefit in those ids, so go ahead.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] $Id$ CVS keyword

[David G. <dga...@gm...>]

Hello!

Most of source files in the repository have the keyword "$Id$" from the CVS era.
This keyword expanded in some info like the file's revision, last
modification's date and modification's author. Now with git it's not
used anymore.

If nobody has any objection I'm going to delete them.

Re: [Freemint-discuss] Strange behavior with "git add"

[Miro K. <mir...@gm...>]

>
> Remember that we have also usb*.km modules
>
Oops, you're right. Feel free to change .gitignore to match that too. First
I wanted to do something more elegant (which would include *.km files but
not directories) but since that requires two lines per pattern, I've chosen
the easier way.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Strange behavior with "git add"

[David G. <dga...@gm...>]

Hi Miro

2018-02-09 10:22 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Hi David,
>
>> The following paths are ignored by one of your .gitignore files:
>> sys/usb/src.km/ucd
>> sys/usb/src.km/udd
>> Use -f if you really want to add them.
>> fatal: no files added
>>
>> I don't see those paths in .gitignore
>
> Actually this is a bug introduced by git migration. The issue here is this
> entry in .gitignore:
>
> *.km
>
> The intention is clear, it is supposed to ignore xaaes*.km files. Too bad it
> ignores also *.km directories. :)
>
> I've pushed the fix, thanks for spotting this!
>

Remember that we have also usb*.km modules

Re: [Freemint-discuss] Strange behavior with "git add"

[Miro K. <mir...@gm...>]

Hi David,

The following paths are ignored by one of your .gitignore files:
> sys/usb/src.km/ucd
> sys/usb/src.km/udd
> Use -f if you really want to add them.
> fatal: no files added
>
> I don't see those paths in .gitignore

Actually this is a bug introduced by git migration. The issue here is this
entry in .gitignore:

*.km

The intention is clear, it is supposed to ignore xaaes*.km files. Too bad
it ignores also *.km *directories*. :)

I've pushed the fix, thanks for spotting this!

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] Strange behavior with "git add"

[David G. <dga...@gm...>]

Hi!

I got this answer while entering this git command:

$ git add usb/src.km/global.h usb/src.km/hub.c
usb/src.km/ucd/unicorn/sl811-hcd.c
usb/src.km/udd/storage/usb_storage.c usb/src.km/usb.c
The following paths are ignored by one of your .gitignore files:
sys/usb/src.km/ucd
sys/usb/src.km/udd
Use -f if you really want to add them.
fatal: no files added

I don't see those paths in .gitignore, I don't have any other
.gitignore in the repository beside the one at the root directory, and
any .gitignore_global either at my local home directory. Using the
"-f" option as suggested let me add the files but I find the behavior
strange.

Re: [Freemint-discuss] Debugging

[Markus F. <mf...@mu...>]

Am 06.02.2018 um 06:38 schrieb Mark Duckworth:
> I didn't think to try with Emutos which might make all the difference.
> I was using Tos 2.06.  The issue is that reads/writes don't really work
> properly.  I am able to get it to mostly boot to XaAES with the old fast
> fs but when I use newfatfs I get some RWABS error whose specific code I
> can't remember.  I believe it was "attempt to read past end of
> partition".  Which kind of disk mode are you using.  Are you using an
> ACSI or are you using the hybrid SD mode?
I'm using an ACSI image on SD. Can try TOS2.06 when I'm at my MiST next
time (but this might take a while).

Re: [Freemint-discuss] Debugging

[Mark D. <mdu...@at...>]

I didn't think to try with Emutos which might make all the difference.
I was using Tos 2.06.  The issue is that reads/writes don't really work
properly.  I am able to get it to mostly boot to XaAES with the old fast
fs but when I use newfatfs I get some RWABS error whose specific code I
can't remember.  I believe it was "attempt to read past end of
partition".  Which kind of disk mode are you using.  Are you using an
ACSI or are you using the hybrid SD mode?

Thanks,
Mark


On 02/06/2018 12:08 AM, Markus Fröschle wrote:
> I'm wondering what Rwabs() issue we might have on MiST?
> 
> Works for me (EmuTOS 0.9.9 + FreeMiNT latest), mainly. Some issues with
> warm resets (such that 'reboot' doesn't work reliably, but hangs with
> scrambled screen most of the time) but other than that, it's working
> fine, fast (faster than a real Falcon) and pretty stable.
> 
> I'd assume the reboot failure is caused by the MiST core's handling of
> the asynchronous reset and not a FreeMiNT code issue.
> 

Re: [Freemint-discuss] Debugging

[Markus F. <mf...@mu...>]

I'm wondering what Rwabs() issue we might have on MiST?

Works for me (EmuTOS 0.9.9 + FreeMiNT latest), mainly. Some issues with
warm resets (such that 'reboot' doesn't work reliably, but hangs with
scrambled screen most of the time) but other than that, it's working
fine, fast (faster than a real Falcon) and pretty stable.

I'd assume the reboot failure is caused by the MiST core's handling of
the asynchronous reset and not a FreeMiNT code issue.


Am 06.02.2018 um 01:04 schrieb Mark Duckworth:
> Hello all,
>
> I was considering working on the freemint kernel, specifically the RWABS
> issue on MiST.  I was wondering what your preferred way is to debug
> problems... serial console/debugging, turning up the console output
> error level, or what.  And what way do you have to upload new kernelot
> builds quickly.  How would you go about debugging an io issue that
> prevents the filesystem from working (broad strokes here, I'm just
> looking for something to start with).  Is there a way to step debug the
> kernel and view memory?  I guess not as you would need something like a
> BDM cable.
>
> Thanks,
> Mark
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Debugging

[Thorsten O. <ad...@th...>]

On Dienstag, 6. Februar 2018 01:28:00 CET Miro Kropáček wrote:
> I rely mostly on Aranym's /dev/nfstderr device, so in a way, the serial
> console, yes.

When running under Aranym, i prefer the direct output via nf_call(NF_STDERR , 
...) calls. That has the big advantage that the output goes to the terminal 
where you started it, and does not mess up the atari screen in any way.

However, i think that does not help in his case, as he is running MiNT on real 
hardware (even if it is a clone)

Re: [Freemint-discuss] Debugging

[Miro K. <mir...@gm...>]

Hi,

I was wondering what your preferred way is to debug problems...

I rely mostly on Aranym's /dev/nfstderr device, so in a way, the serial
console, yes. Many parts of the kernel offer additional detailed debugging
via #if 0's if needed. So I just usually collect a few MBs of data, look
what's happening, add / remove some outputs and fix the issue if possible.
If you can get to the desktop, it's nicer for real hardware as you can use
TosWin2 for debugging (/dev/xconout2 device).

Oh and often I just let the kernel crash, some kind of really strong
assert. ;-)

This has been usually enough for debugging even such fine grained issues as
this one:
https://github.com/freemint/freemint/issues/40#issuecomment-304434775

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] Debugging

[Mark D. <mdu...@at...>]

Hello all,

I was considering working on the freemint kernel, specifically the RWABS
issue on MiST.  I was wondering what your preferred way is to debug
problems... serial console/debugging, turning up the console output
error level, or what.  And what way do you have to upload new kernel
builds quickly.  How would you go about debugging an io issue that
prevents the filesystem from working (broad strokes here, I'm just
looking for something to start with).  Is there a way to step debug the
kernel and view memory?  I guess not as you would need something like a
BDM cable.

Thanks,
Mark

Re: [Freemint-discuss] list address in README.md

[Miro K. <mir...@gm...>]

On 28 January 2018 at 22:01, Vincent Rivière <vin...@fr...>
wrote:

> On 28/01/2018 at 06:32, Miro Kropáček wrote:
>
>> That's exactly why it's on github: fork -> edit -> pull request. 100% web
>> gui operations.
>>
>
> In any foreign project, in the File view, look on the right (see
> screenshot).
> There is even a "pen" button to automate the whole "fork / pull request"
> process.

I'll be damned, I had no idea you can do that directly. Thanks!

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] RPMint

[Jean-François L. <jfl...@sk...>]

On Saturday, 27 January 2018 15:46:49 CET Mark Duckworth wrote:

> or the author of easymint will be able to
> create a new easymint distribution based on rpmint. 

EasyMint is an abandonded project.

Cheers,
JFL
-- 
Jean-François Lemaire

Re: [Freemint-discuss] list address in README.md

[Vincent R. <vin...@fr...>]

On 28/01/2018 at 06:32, Miro Kropáček wrote:
> That's exactly why it's on github: fork -> edit -> pull request. 100% web
> gui operations.

In any foreign project, in the File view, look on the right (see screenshot).
There is even a "pen" button to automate the whole "fork / pull request" 
process.

-- 
Vincent Rivière

Re: [Freemint-discuss] list address in README.md

[David G. <dga...@gm...>]

2018-01-28 6:32 GMT+01:00 Miro Kropáček <mir...@gm...>:
> That's exactly why it's on github: fork -> edit -> pull request. 100% web
> gui operations.
>
> On 28 January 2018 at 16:30, Paul Wratt <pau...@gm...> wrote:
>>
>> needs updateing
>>

OK, I've just updated it.

Thanks