Menu
▾
▴
freemint-discuss — The official FreeMiNT Mailing List
You can subscribe to this list here.
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(30) |
Dec
(10) |
| 2018 |
Jan
(44) |
Feb
(44) |
Mar
(32) |
Apr
(49) |
May
(45) |
Jun
(7) |
Jul
(15) |
Aug
(84) |
Sep
(95) |
Oct
(36) |
Nov
(88) |
Dec
(41) |
| 2019 |
Jan
(21) |
Feb
(27) |
Mar
(67) |
Apr
(25) |
May
(69) |
Jun
(45) |
Jul
(65) |
Aug
(15) |
Sep
(20) |
Oct
(42) |
Nov
(109) |
Dec
(62) |
| 2020 |
Jan
(58) |
Feb
(36) |
Mar
(84) |
Apr
(169) |
May
(325) |
Jun
(267) |
Jul
(43) |
Aug
(3) |
Sep
(27) |
Oct
(25) |
Nov
(25) |
Dec
(7) |
| 2021 |
Jan
(11) |
Feb
(66) |
Mar
(1) |
Apr
(55) |
May
(24) |
Jun
(36) |
Jul
(10) |
Aug
|
Sep
(1) |
Oct
(21) |
Nov
(2) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(98) |
Mar
(15) |
Apr
(31) |
May
(4) |
Jun
(23) |
Jul
(45) |
Aug
(15) |
Sep
(75) |
Oct
(8) |
Nov
(10) |
Dec
(12) |
| 2023 |
Jan
(5) |
Feb
(49) |
Mar
(31) |
Apr
(3) |
May
(7) |
Jun
(5) |
Jul
(7) |
Aug
(161) |
Sep
(8) |
Oct
(7) |
Nov
(27) |
Dec
(26) |
| 2024 |
Jan
(24) |
Feb
(35) |
Mar
(11) |
Apr
(38) |
May
(13) |
Jun
(39) |
Jul
(2) |
Aug
(24) |
Sep
(7) |
Oct
(5) |
Nov
|
Dec
(18) |
| 2025 |
Jan
(82) |
Feb
(11) |
Mar
(9) |
Apr
(13) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(38) |
Sep
(46) |
Oct
(13) |
Nov
(3) |
Dec
|
|
From: Thorsten O. <ad...@th...> - 2018-05-18 09:29:42
|
On Freitag, 18. Mai 2018 10:57:10 CEST David Gálvez wrote: > I've attached the patch for you to take a look in case you want to > comment anything. Might be cleaner to write ndelay as #define ndelay(n) ndelay_loops(getloops4ns(n)) Also i'm not entirely sure whether the DIV_ROUND_UP macro is used correctly there, you are rounding up the number of loops there? Wouldn't that give way too large values on slower processors? |
|
From: David G. <dga...@gm...> - 2018-05-18 08:57:18
|
Hello! I'd like to add a delay function for nanoseconds for driver to use, similar to udelay() and mdelay(). The problem is that the count loop calculation takes probably the time the driver needs to wait or may be more in our machines. So I was thinking to use another approach, adding two functions, one than calculates the loops given a number of nanoseconds, getloops4ns( ), then in the loading part of the driver code the driver gets the loops for the delays it needs, for example if it needs 150 ns and 500 ns it will do: delay_150ns = getloops4ns(150) delay_500ns = getloops4ns(500) and then when the delay is need it, it will call the second function that loops directly. ndelay_loops(delay_150ns) ndelay_loops(delay_500ns) so we don't have the loop calculation overhead in the use moment. The ndelay() function still will be available. I've attached the patch for you to take a look in case you want to comment anything. |
|
From: Mark D. <mdu...@at...> - 2018-05-17 15:50:13
|
When I tried on my mega ste with monster I think I had to use 1.15 stack as nothing later worked. This is from a very fuzzy memory but I remember it being troublesome for sure. Thanks, Mark On 05/17/2018 11:48 AM, David Gálvez wrote: > Hi list, > > Has anybody tried to use MiNT's network stack with a ST recently? > > Somebody made some tests for me with MiNT and the RTL8012 driver for > the ST, and there were some issues but I think they're unrelated with > the driver but with MiNT's ST support. |
|
From: David G. <dga...@gm...> - 2018-05-17 15:49:02
|
Hi list, Has anybody tried to use MiNT's network stack with a ST recently? Somebody made some tests for me with MiNT and the RTL8012 driver for the ST, and there were some issues but I think they're unrelated with the driver but with MiNT's ST support. |
|
From: Miro K. <mir...@gm...> - 2018-05-06 13:35:39
|
On 6 May 2018 at 21:19, Mark Duckworth <mdu...@at...> wrote: > In my case the ctpci ribbon went through the power connector and fried > the CTPCI at some point. It got repaired and this is the repaired one. > I wonder if there is some other very minor damage that causes > intermittent problems. That would be very sad. > What happens if you remove CTPCI and keep Ethernat? That should narrow it down significantly. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Mark D. <mdu...@at...> - 2018-05-06 13:19:21
|
I don't believe my problem is CPU. Specifically because I can build large software packages without compiler errors. However, if I add some network traffic things go haywire with very little running. mint booted with as little running as possible to bash shell, ssh to a server and tail a log and it will get a memory violation soon. Heavy cpu use or heavy memory use alone - no problem. For some reason moving the mouse a lot while loading xcontrol can always cause a memory violation. Even when the system otherwise appears stable. I wonder if that is just an actual bug and I should look to triggering other issues. I can also cause memory violations with specific sequences of actions in Thing and it threw me off for a long time until I tried it on the beepi and it did the same thing. Not fun to chase software bugs thinking it's hardware. Right now I have a bleeding edge 1.19 kernel loaded with no ethernat board and it is rock solid but I need to get PPP to work or throw an ethernec in (which will require extraction from a well setup mega ste). I wonder if Rodolphe could make a "safer timing" version of the ABE/ADR. Seems like everything is tuned to the limit. Also my cpu speed is 92MHz, but I have the same issues exactly at 50MHz. In my case the ctpci ribbon went through the power connector and fried the CTPCI at some point. It got repaired and this is the repaired one. I wonder if there is some other very minor damage that causes intermittent problems. That would be very sad. Thanks, Mark On 05/06/2018 07:14 AM, David Gálvez wrote: > 2018-05-06 4:38 GMT+02:00 Mark Duckworth <mdu...@at...>: >> 1.17 is not perfectly stable but it is orders of magnitude more stable, >> to the point that you can get some use out of it. For instance i can >> run conholio on a busy terminal for days with no problem. I do believe >> now though that the later kernels are just better at showing a hardware >> issue that is present in 1.17 as well. >> >> With the ethernat pulled 1.19 4c3 seems perfect. I'll need to put an >> ethernec in to really beat it up and verify in all scenarios but I >> believe the issue is some kind of bus loading/interrupt issue on the 060 >> side. I have as far as I know all the most recent ABE/SDR and CTPCI >> images and the ones that are valid for my setup. >> >> My CTPCI was corrupting IDE transfers too. I am curious if it still >> does it with the ethernat removed now that things seem more stable. > Your problems seems very similar with what I had with my old CT60. > I noticed that something was wrong while compiling intensive stuff > like the kernel, I got random compiler errors, memory protection was > off probably. > Things got worse when I got the Supervidel and I plugged it together > with the EtherNat. After some tests I realized that the only stable > configuration was having only one card plugged with the CPU speed set > at 66 Mhz, any increase of the speed made the system unstable again, > CPU was a rev.6. > Then during a Sommarhack party in Sweden together with the "Nature > brothers" we did many tests, we tried exchanging components in our > systems, the Falcon, memory modules, cards even the CPU, at the end > all pointed to my CT60, we made sure we have the same firmware, but > for some reason my CT60 didn't like overclocking and having more than > one card attached. > The theory suggested then to explain my CT60 behavior was the > malfunction of one of the CPLD chips, I don't remember if it was the > ABE or the SDR. I remember we talked about that there were different > versions of the same chip, one with lower specification for a property > that I don't remember but the unit of measure was in nanoseconds, > there were versions with 20 ns for this property and others with 25 > ns, or some similar values, we speculated on some CT60 being assembled > with one of the lower version of the chip although marked as a better > one. > > ------------------------------------------------------------------------------ > 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 |
|
From: David G. <dga...@gm...> - 2018-05-06 11:14:14
|
2018-05-06 4:38 GMT+02:00 Mark Duckworth <mdu...@at...>: > 1.17 is not perfectly stable but it is orders of magnitude more stable, > to the point that you can get some use out of it. For instance i can > run conholio on a busy terminal for days with no problem. I do believe > now though that the later kernels are just better at showing a hardware > issue that is present in 1.17 as well. > > With the ethernat pulled 1.19 4c3 seems perfect. I'll need to put an > ethernec in to really beat it up and verify in all scenarios but I > believe the issue is some kind of bus loading/interrupt issue on the 060 > side. I have as far as I know all the most recent ABE/SDR and CTPCI > images and the ones that are valid for my setup. > > My CTPCI was corrupting IDE transfers too. I am curious if it still > does it with the ethernat removed now that things seem more stable. Your problems seems very similar with what I had with my old CT60. I noticed that something was wrong while compiling intensive stuff like the kernel, I got random compiler errors, memory protection was off probably. Things got worse when I got the Supervidel and I plugged it together with the EtherNat. After some tests I realized that the only stable configuration was having only one card plugged with the CPU speed set at 66 Mhz, any increase of the speed made the system unstable again, CPU was a rev.6. Then during a Sommarhack party in Sweden together with the "Nature brothers" we did many tests, we tried exchanging components in our systems, the Falcon, memory modules, cards even the CPU, at the end all pointed to my CT60, we made sure we have the same firmware, but for some reason my CT60 didn't like overclocking and having more than one card attached. The theory suggested then to explain my CT60 behavior was the malfunction of one of the CPLD chips, I don't remember if it was the ABE or the SDR. I remember we talked about that there were different versions of the same chip, one with lower specification for a property that I don't remember but the unit of measure was in nanoseconds, there were versions with 20 ns for this property and others with 25 ns, or some similar values, we speculated on some CT60 being assembled with one of the lower version of the chip although marked as a better one. |
|
From: Thorsten O. <ad...@th...> - 2018-05-06 09:54:37
|
Hi, GCC 8.1 has been released a few days ago, and new cross-compilers are available here (older 7.3 version is still available there, too, just in case). binutils is still 2.30, as there has been no new release yet. |
|
From: Thorsten O. <ad...@th...> - 2018-05-06 06:33:02
|
On Samstag, 5. Mai 2018 23:58:52 CEST Peter Slegg wrote: > Is there any risk of losing a.out support elsewhere ? I don't hope so. If that happens, a.out might be removed completely. |
|
From: Mark D. <mdu...@at...> - 2018-05-06 02:38:29
|
1.17 is not perfectly stable but it is orders of magnitude more stable, to the point that you can get some use out of it. For instance i can run conholio on a busy terminal for days with no problem. I do believe now though that the later kernels are just better at showing a hardware issue that is present in 1.17 as well. With the ethernat pulled 1.19 4c3 seems perfect. I'll need to put an ethernec in to really beat it up and verify in all scenarios but I believe the issue is some kind of bus loading/interrupt issue on the 060 side. I have as far as I know all the most recent ABE/SDR and CTPCI images and the ones that are valid for my setup. My CTPCI was corrupting IDE transfers too. I am curious if it still does it with the ethernat removed now that things seem more stable. Thanks, Mark On 05/05/2018 08:29 PM, Miro Kropáček wrote: > Do you need to remove the ethernat physically or just the driver? If > it's the former then I'd definitely suspect some obscure hardware > problem. But I remember you saying that it doesn't happen on 1.17 > kernels, is it still true? > |
|
From: Mark D. <mdu...@at...> - 2018-05-06 02:20:34
|
Indeed that makes sense, however you can't use ppp without slip.xif module as far as I can tell. Thanks, Mark On 05/05/2018 08:27 PM, Miro Kropáček wrote: > Hi Mark, > > this has been discussed several times, the initial post > here: https://mikro.naprvyraz.sk/mint/201312/msg00143.html > |
|
From: Miro K. <mir...@gm...> - 2018-05-06 00:29:08
|
Do you need to remove the ethernat physically or just the driver? If it's the former then I'd definitely suspect some obscure hardware problem. But I remember you saying that it doesn't happen on 1.17 kernels, is it still true? On 6 May 2018 at 07:38, Mark Duckworth <mdu...@at...> wrote: > Hello all, > > I was also wondering if anyone runs a modern (1.19 kernel) on a CT60 > falcon with CTPCI, with or without ethernat? I am having a lot of > trouble with memory violations and the situation is very strange. I > seem to be able to cause the issue by moving the mouse quickly during > heavy IDE I/O. Removing the ethernat and using PPP appears to improve > things but I have further testing to do. I am trying to figure out if > memory protection is pointless on this setup or if my system has a > genuine problem. > > The thing is I don't ever get disk corruption, I've run intense test of > both st ram and alt ram. I've run demos for hours and hours. I've > played mp3 via aniplayer dsp for hours and hours. All of the systems > seem to work on their own but as soon as the mint kernel is involved all > hell breaks loose. Often times when I cause the crash I'll get an > exception processing after reboot and I will have to physically shut > down and restart the system. I believe hardware but how... How would > mouse movements during disk cause memory issues? Anyone have any idea > how to narrow it down? I've already triggered it with ethernat removed > and now I will remove ctpci shortly. I'd really love to figure it out > but I'm running out of ideas. > > 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 > -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2018-05-06 00:27:14
|
Hi Mark, this has been discussed several times, the initial post here: https://mikro.naprvyraz.sk/mint/201312/msg00143.html On 6 May 2018 at 07:12, Mark Duckworth <mdu...@at...> wrote: > Hey all, > > How come this doesn't seem to ever be built into current kernels? > Either through the trunk builds or the other bintray builds? > > 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 > -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Mark D. <mdu...@at...> - 2018-05-05 23:39:04
|
Hello all, I was also wondering if anyone runs a modern (1.19 kernel) on a CT60 falcon with CTPCI, with or without ethernat? I am having a lot of trouble with memory violations and the situation is very strange. I seem to be able to cause the issue by moving the mouse quickly during heavy IDE I/O. Removing the ethernat and using PPP appears to improve things but I have further testing to do. I am trying to figure out if memory protection is pointless on this setup or if my system has a genuine problem. The thing is I don't ever get disk corruption, I've run intense test of both st ram and alt ram. I've run demos for hours and hours. I've played mp3 via aniplayer dsp for hours and hours. All of the systems seem to work on their own but as soon as the mint kernel is involved all hell breaks loose. Often times when I cause the crash I'll get an exception processing after reboot and I will have to physically shut down and restart the system. I believe hardware but how... How would mouse movements during disk cause memory issues? Anyone have any idea how to narrow it down? I've already triggered it with ethernat removed and now I will remove ctpci shortly. I'd really love to figure it out but I'm running out of ideas. Thanks, Mark |
|
From: Mark D. <mdu...@at...> - 2018-05-05 23:12:23
|
Hey all, How come this doesn't seem to ever be built into current kernels? Either through the trunk builds or the other bintray builds? Thanks, Mark |
|
From: Peter S. <p....@sc...> - 2018-05-05 21:58:58
|
On Sat, 05 May 2018 11:31:54 , Thorsten Otto <ad...@th...> wrote: > On Samstag, 5. Mai 2018 11:15:08 CEST Peter Slegg wrote: > > Also, if the migration to elf begins, > > did i miss anything? :-) I think it might happen eventually. > Sure, 2.30 is maybe the last official version with > support for m68k+a.out, but as for now there is no urgent need to switch to > elf. Also, i have already patches here to add back in that support. Is there any risk of losing a.out support elsewhere ? Peter |
|
From: Thorsten O. <ad...@th...> - 2018-05-05 09:32:04
|
On Samstag, 5. Mai 2018 11:15:08 CEST Peter Slegg wrote: > Also, if the migration to elf begins, did i miss anything? Sure, 2.30 is maybe the last official version with support for m68k+a.out, but as for now there is no urgent need to switch to elf. Also, i have already patches here to add back in that support. |
|
From: Peter S. <p....@sc...> - 2018-05-05 09:15:22
|
On Fri, 04 May 2018 23:02:30 , Thorsten Otto <ad...@th...> wrote: > On Freitag, 4. Mai 2018 21:41:36 CEST Peter Slegg wrote: > > I suspect this is because you were aiming at > > cross-compiling. > > Yes, i used a slightly modified version of the script that i also use for > cross-compiling. The native versions where just a try, i stopped working on it > when i had a somewhat lengthy discussion with mirko, and we couldn't decide > wether the '020 compiler should also produce '020 executables by default, > because that would require a different lib directory layout for the '000 and > the '020 version. > > BTW do you have some specific need of newer features that aren't supported by > older versions, or just wanted to have a "recent" version? > > No great need for new features but with the elf discussion I looked at my binutils and saw how old they were. I like to keep things updated if I can. Also, if the migration to elf begins, I might try to help with some testing. Regards, Peter |
|
From: Thorsten O. <ad...@th...> - 2018-05-04 21:02:42
|
On Freitag, 4. Mai 2018 21:41:36 CEST Peter Slegg wrote: > I suspect this is because you were aiming at > cross-compiling. Yes, i used a slightly modified version of the script that i also use for cross-compiling. The native versions where just a try, i stopped working on it when i had a somewhat lengthy discussion with mirko, and we couldn't decide wether the '020 compiler should also produce '020 executables by default, because that would require a different lib directory layout for the '000 and the '020 version. BTW do you have some specific need of newer features that aren't supported by older versions, or just wanted to have a "recent" version? |
|
From: Peter S. <p....@sc...> - 2018-05-04 19:41:48
|
On Thu, 03 May 2018 09:05:21 , Thorsten Otto <ad...@th...> wrote: > On Mittwoch, 2. Mai 2018 18:28:10 CEST Peter Slegg wrote: > > Native ones ? > > There are native versions for 2.29.1, but they don't appear on the links page: > > http://tho-otto.de/download/mint/binutils-2.29.1-mint-000.tar.xz > http://tho-otto.de/download/mint/binutils-2.29.1-mint-020.tar.xz > http://tho-otto.de/download/mint/binutils-2.29.1-mint-v4e.tar.xz > > Thanks. 020 versions installed but I removed some of the links and renamed the m68k files. I suspect this is because you were aiming at cross-compiling. I may try to create an rpm. Peter |
|
From: David G. <dga...@gm...> - 2018-05-03 19:09:21
|
2018-04-25 9:14 GMT+02:00 David Gálvez <dga...@gm...>: > > > The information given by this system call is independent from the > machine you're running the kernel on, so it can be a bit confusing. > It's the option it was used to compile the kernel. > If you're using a 060 kernel with FireTOS it will return 68060 but if > you are using a 5475 kernel it will return a ColdFire kernel with > isa_b instruction set. > From the documentation: > "This is not the same as the _CPU cookie value. The _CPU cookie > specifies the CPU physically present in the machine, while the > S_OSCOMPILE indicates the processor type selected at the time when the > system was compiled. In other words, running a 68000-compiled kernel > will return a 0x00 here, even if the machine is running 68040 or > something." I've just had a real situation where to know some compile time flags has been useful. I was testing transferring files to/from a USB device with a kernel with -DOLDTOSFS flag, after doing some transfers (it's a 100 MB zip file and through the ROM-port it takes some minutes) I wasn't sure if I loaded the right kernel, then I remember that a XaAES's menu option shows the flags the kernel running has been built with, and I saw that it was the wrong kernel, without the -DOLDTOSFS flag. |
|
From: David G. <dga...@gm...> - 2018-05-03 07:33:45
|
2018-05-03 9:05 GMT+02:00 Thorsten Otto <ad...@th...>: > On Mittwoch, 2. Mai 2018 18:28:10 CEST Peter Slegg wrote: >> Native ones ? > > There are native versions for 2.29.1, but they don't appear on the links page: > > http://tho-otto.de/download/mint/binutils-2.29.1-mint-000.tar.xz > http://tho-otto.de/download/mint/binutils-2.29.1-mint-020.tar.xz > http://tho-otto.de/download/mint/binutils-2.29.1-mint-v4e.tar.xz > > PS.: does SF has problems again? my mail took 2 days to arrive > It looks like, Christian complained too yesterday in EmuTOS mailing list. |
|
From: Thorsten O. <ad...@th...> - 2018-05-03 07:14:35
|
> Your website just returns a blank page with Netsurf. Did you mean my website or Mirko's? I just tried, and it works. |
|
From: Thorsten O. <ad...@th...> - 2018-05-03 07:05:34
|
On Mittwoch, 2. Mai 2018 18:28:10 CEST Peter Slegg wrote: > Native ones ? There are native versions for 2.29.1, but they don't appear on the links page: http://tho-otto.de/download/mint/binutils-2.29.1-mint-000.tar.xz http://tho-otto.de/download/mint/binutils-2.29.1-mint-020.tar.xz http://tho-otto.de/download/mint/binutils-2.29.1-mint-v4e.tar.xz PS.: does SF has problems again? my mail took 2 days to arrive |
|
From: Jean-François L. <jfl...@sk...> - 2018-05-02 20:24:55
|
On Tuesday, 1 May 2018 22:00:44 CEST Vincent Rivière wrote: > I'm glad to announce that last week, I have made a presentation at > foss-north 2018, in Gothenburg, Sweden. > Topic was: Atari ST Free Operating Systems Excellent job, Vincent. I particulary appreciate that you so prominentely present other people's work. Cheers, JFL -- Jean-François Lemaire |
5 messages has been excluded from this view by a project administrator.
