Overview Features Coding Performance Forum Downloads Products OrderV4 Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

Building a Nommu Linux Kernel for Amiga M68kpage  1 2 

Carlos Milán

Posts 95
27 Sep 2020 12:22


I wonder if anyone have been successful in  compiling a Linux kernel for m68k with nommu that is bootable on Amiga. Yesterday night I used a buildroot.org configuration for the ColdFire MFC5208 and it compiles successfully, but this kernel won't boot with amiboot... :/ Anyone tried such a thing?

There is a person who achieved this on the Atari ST and I am sure it should be possible on even an Amiga 500 with enough memory... And of course in Apollo Core at lightning speed. EXTERNAL LINK


Vojin Vidanovic
(Needs Verification)
Posts 1896/ 1
27 Sep 2020 20:09


Carlos Milán wrote:

I wonder if anyone have been successful in  compiling a Linux kernel for m68k with nommu that is bootable on Amiga. Yesterday night I used a buildroot.org configuration for the ColdFire MFC5208 and it compiles successfully, but this kernel won't boot with amiboot... :/ Anyone tried such a thing?

All Amiga Linux distro a requirew a MMU, so answer is No.

Best chance is uclinux EXTERNAL LINK 
That is unless team provides its own Linux kernel, which is no priority for them, if ever happens.

Too bad, Linux is not bad at 060 and 100mb fast and would provide a bit newer software.



J.M. Lapilainen

Posts 24
27 Sep 2020 20:14


Last time I tried with Vampire, there were some issues with amiboot, might have been something to do with runtime cpu/machine detection if I recall correctly and it got confused and crashed. It's been couple of years so..
 
  There might have been something with nommu config options not including platform support properly for Amiga but again, it's been awhile and can't remember anymore. Anyway, it won't boot with Coldfire defconfig, I'm pretty sure it doesn't include support for Amiga chipset.


Carlos Milán

Posts 95
27 Sep 2020 21:45


J.M. Lapilainen wrote:

  Last time I tried with Vampire, there were some issues with amiboot, might have been something to do with runtime cpu/machine detection if I recall correctly and it got confused and crashed. It's been couple of years so..
   
    There might have been something with nommu config options not including platform support properly for Amiga but again, it's been awhile and can't remember anymore. Anyway, it won't boot with Coldfire defconfig, I'm pretty sure it doesn't include support for Amiga chipset.
 

  That's just what's happening, Coldfire defconfig is what I was trying yesterday without success (amiboot won't load the kernel on memory). It was the only m68k nommu architecture supported in buildroot; but I think you may be right in which it actually maps to the current Linux kernel itself where CONFIG_MMU=n and m68k-amiga doesn't tie together EXTERNAL LINK 

  The only thing that bothers me, is that that should be also true for the Atari ST. Maybe that person patched the needed things to run on it.


J.M. Lapilainen

Posts 24
27 Sep 2020 22:43


Carlos Milán wrote:

  The only thing that bothers me, is that that should be also true for the Atari ST. Maybe that person patched the needed things to run on it.

Yeah, probably. Google found this: EXTERNAL LINK 
I'll take a closer look at it if I manage to find some spare time.


Carlos Milán

Posts 95
27 Sep 2020 22:56


Vojin Vidanovic wrote:
 
  All Amiga Linux distro a requirew a MMU, so answer is No.
 
  Best chance is uclinux EXTERNAL LINK 
  That is unless team provides its own Linux kernel, which is no priority for them, if ever happens.
 
  Too bad, Linux is not bad at 060 and 100mb fast and would provide a bit newer software.

I have not asked about Linux distro. My experiment is simple: ucLinux that was a project for running Linux kernel in embbeded devices, even without MMU. It was integrated into mainstream kernel and currently it can be enabled through the CONFIG_MMU directive (saying "n"!).

It should have been fairly simple to build a MMU-less m68k Linux kernel that would be able to run flat binaries (in contrast with ELF, that require MMU), as some tools like busybox are easy to be compiled as flat. That kernel and a small rootfs with basic tools would have been an interesting tool set in Amiga. This could have been the starting point for building a new MMU-less m68k Linux mini-distro, that would be friendly with Apollo Core or EC variants CPUs.

However, while doing all of this was easy with the ColdFire defconf, it looks like the mainstream Linux kernel has dropped the no-MMU support for classic m68k processors, so dead end :(

I guess alternative would be to build an old kernel were classic m68k and nommu Linux still works.

About Apollo Core devs, their efforts are way better put on AROS. Linux is just a geeky thing in the Amiga :) However, if the Apollo Core truly has a PMMU, it would be nice if they publish the needed info for a kernel hacker to implement support for the native MMU in mainstream kernel.


Nick Fellows

Posts 116
28 Sep 2020 08:12


Its an interesting thought. I remember reading that Commodore were considering Linux / Unix as the basis next evolution of the Amiga OS.


Vojin Vidanovic
(Needs Verification)
Posts 1896/ 1
28 Sep 2020 14:14


Carlos Milán wrote:
 
    However, while doing all of this was easy with the ColdFire defconf, it looks like the mainstream Linux kernel has dropped the no-MMU support for classic m68k processors, so dead end :(
   
    I guess alternative would be to build an old kernel were classic m68k and nommu Linux still works.
   

   
  ColdFire and m68k no MMU are NO full compatibile.
 
    Try contacting ucLinux even their distro has not been updated for couple of years. I am sure m68k no MMU was supported platform once.
    There have been couple of demonstrations on You tube of similar task to one you have proposed, but only with uclinux.
   
    Update>
    Seems this is successor
    EXTERNAL LINK   
    This is ucLinux port to Atari 040
    https://web.archive.org/web/20140922035613 EXTERNAL LINK   
    As you note, mainstream Linux kernel always needed MMU, uclinux was only kernel and small distro that targetted mmuless embeded systems
   
   
Carlos Milán wrote:
 
    About Apollo Core devs, their efforts are way better put on AROS. Linux is just a geeky thing in the Amiga :) However, if the Apollo Core truly has a PMMU, it would be nice if they publish the needed info for a kernel hacker to implement support for the native MMU in mainstream kernel.
   

   
    Fully agreed, try contacting Apollo Team on discord. While they have never published PMMU info publicly, they might be willing to offer it to someone willing to devote to task.
   
    There is even Deb10 ported to m68k with MMU
  *as source of some newer kernel to be hacked
    EXTERNAL LINK   
At same time distro and kernel with Amiga support is
Debian 3.1x EXTERNAL LINK  Debian 9 EXTERNAL LINK 

    Good luck!


Dj Up

Posts 37
28 Feb 2021 16:56


Vojin Vidanovic wrote:

Carlos Milán wrote:
 
      However, while doing all of this was easy with the ColdFire defconf, it looks like the mainstream Linux kernel has dropped the no-MMU support for classic m68k processors, so dead end :(
     
      I guess alternative would be to build an old kernel were classic m68k and nommu Linux still works.
   

   
    ColdFire and m68k no MMU are NO full compatibile.
   
    Try contacting ucLinux even their distro has not been updated for couple of years. I am sure m68k no MMU was supported platform once.
    There have been couple of demonstrations on You tube of similar task to one you have proposed, but only with uclinux.
   
    Update>
    Seems this is successor
    EXTERNAL LINK     
    This is ucLinux port to Atari 040
    https://web.archive.org/web/20140922035613 EXTERNAL LINK     
    As you note, mainstream Linux kernel always needed MMU, uclinux was only kernel and small distro that targetted mmuless embeded systems
   
   
Carlos Milán wrote:
 
      About Apollo Core devs, their efforts are way better put on AROS. Linux is just a geeky thing in the Amiga :) However, if the Apollo Core truly has a PMMU, it would be nice if they publish the needed info for a kernel hacker to implement support for the native MMU in mainstream kernel.
   

   
    Fully agreed, try contacting Apollo Team on discord. While they have never published PMMU info publicly, they might be willing to offer it to someone willing to devote to task.
   
    There is even Deb10 ported to m68k with MMU
  *as source of some newer kernel to be hacked
    EXTERNAL LINK     
  At same time distro and kernel with Amiga support is
  Debian 3.1x EXTERNAL LINK  Debian 9 EXTERNAL LINK 
 
    Good luck!

Greetings everyone.

I just wanted to write in on this since I had a try with Debian-31r8 hdf inside FS-UAE. It actually starts booting Debian, but gets a kernal panic (classic stuff) and there its stuck.

The 3 last messages is as follows:

"VFS: Cannot open rood device "hda2" or 03:02"
"Please append a correct "root=" boot option"
"Kernel panic: VFS: Unable to mount root fs on 03:02"

I was thinking about trying hdf-file as a secondary drive and try boot into something else and have a look at what this issue is,but I also realize that it could be a FS-UAE (or settings by be) issue.As logic would have it so that whomever made this hdf-file available did at least on one system get it to boot through.

Debian 9 in the link from aminet is interesting,but at the moment I got stuck because unpacked the file is not a hdf-file but I guess a binary file. I am not really sure how to get that one tested,but Debian 9 is quite new,and its really interesting to figure out how well it works,what works,and what does not and so on.

I will of course look into this more and run into some "roadblocks" for myself since I am very limited in my Amiga knowledge, and to be rather honest I`m no deep-into-kernel/cross compiling-expert either,no matter what system really. Anyway,the fun part is learning on the way.

Thanks for the very useful and interesting links. 


Bert Smith

Posts 3
01 Mar 2021 15:29


dj up wrote:

  Greetings everyone.
 
  I just wanted to write in on this since I had a try with Debian-31r8 hdf inside FS-UAE. It actually starts booting Debian, but gets a kernal panic (classic stuff) and there its stuck.
 
  The 3 last messages is as follows:
 
  "VFS: Cannot open rood device "hda2" or 03:02"
  "Please append a correct "root=" boot option"
  "Kernel panic: VFS: Unable to mount root fs on 03:02"
 
  I was thinking about trying hdf-file as a secondary drive and try boot into something else and have a look at what this issue is,but I also realize that it could be a FS-UAE (or settings by be) issue.As logic would have it so that whomever made this hdf-file available did at least on one system get it to boot through.
 
  Debian 9 in the link from aminet is interesting,but at the moment I got stuck because unpacked the file is not a hdf-file but I guess a binary file. I am not really sure how to get that one tested,but Debian 9 is quite new,and its really interesting to figure out how well it works,what works,and what does not and so on.
 
  I will of course look into this more and run into some "roadblocks" for myself since I am very limited in my Amiga knowledge, and to be rather honest I`m no deep-into-kernel/cross compiling-expert either,no matter what system really. Anyway,the fun part is learning on the way.
 
  Thanks for the very useful and interesting links. 

This means the kernel has booted successfully, but it cannot find a filesystem to load the userland from. The device "hda2" would refer to the second partition on the first IDE HDD. On a real Amiga this would be an A1200 or A4000.
I believe by default UAE inserts its own hard drive controller and amigaos driver "uaescsi.device" or something which Linux has no driver for.
If you can configure UAE to present an emulated controller that's compatible with real hardware such as the A4000 IDE controller, and then attach a drive to that it should be able to work.


Dj Up

Posts 37
02 Mar 2021 16:49


Bert Smith wrote:

dj up wrote:

  Greetings everyone.
 
  I just wanted to write in on this since I had a try with Debian-31r8 hdf inside FS-UAE. It actually starts booting Debian, but gets a kernal panic (classic stuff) and there its stuck.
 
  The 3 last messages is as follows:
 
  "VFS: Cannot open rood device "hda2" or 03:02"
  "Please append a correct "root=" boot option"
  "Kernel panic: VFS: Unable to mount root fs on 03:02"
 
  I was thinking about trying hdf-file as a secondary drive and try boot into something else and have a look at what this issue is,but I also realize that it could be a FS-UAE (or settings by be) issue.As logic would have it so that whomever made this hdf-file available did at least on one system get it to boot through.
 
  Debian 9 in the link from aminet is interesting,but at the moment I got stuck because unpacked the file is not a hdf-file but I guess a binary file. I am not really sure how to get that one tested,but Debian 9 is quite new,and its really interesting to figure out how well it works,what works,and what does not and so on.
 
  I will of course look into this more and run into some "roadblocks" for myself since I am very limited in my Amiga knowledge, and to be rather honest I`m no deep-into-kernel/cross compiling-expert either,no matter what system really. Anyway,the fun part is learning on the way.
 
  Thanks for the very useful and interesting links. 
 

 
  This means the kernel has booted successfully, but it cannot find a filesystem to load the userland from. The device "hda2" would refer to the second partition on the first IDE HDD. On a real Amiga this would be an A1200 or A4000.
  I believe by default UAE inserts its own hard drive controller and amigaos driver "uaescsi.device" or something which Linux has no driver for.
  If you can configure UAE to present an emulated controller that's compatible with real hardware such as the A4000 IDE controller, and then attach a drive to that it should be able to work.

Hello there.
This is great insights to all of this,and I think you are correct because I had a look into the -uae-config-file (winuae-file,not the same as for fs-uae,for some reason.) that the uploader had put along with it and I noticed some more specific A4000 hd-settings there..

However,it did continue the boot when I changed graphics to Picasso IV,but it went black screen not long after getting further into boot. After it go black I left it for a few minutes to see if it comes back,because fans on my Laptop and CPU-monitor shows FS-UAE working with heavy stuff,or got stuck in a bug,or with my setting.. Nothing happen for 5 mins,so I did not test further than that for now (I will however try on my desktop computer too,to give it some more time),but it was very interesting so far.




Bert Smith

Posts 3
04 Mar 2021 15:29


dj up wrote:
 
  Hello there.
  This is great insights to all of this,and I think you are correct because I had a look into the -uae-config-file (winuae-file,not the same as for fs-uae,for some reason.) that the uploader had put along with it and I noticed some more specific A4000 hd-settings there..
 
  However,it did continue the boot when I changed graphics to Picasso IV,but it went black screen not long after getting further into boot. After it go black I left it for a few minutes to see if it comes back,because fans on my Laptop and CPU-monitor shows FS-UAE working with heavy stuff,or got stuck in a bug,or with my setting.. Nothing happen for 5 mins,so I did not test further than that for now (I will however try on my desktop computer too,to give it some more time),but it was very interesting so far.
 

That's strange, the graphics in use shouldn't make any difference to mounting the root filesystem. Are you sure it actually got further, or did it just fail to initialize the picasso driver and go to a black screen?

You will need to present a storage device that linux recognises, the default uae devices are paravirtualized rather than emulated - ie it presents a uae-specific device rather than emulating a real physical piece of hardware. This method is faster, but it requires drivers - and those drivers presently only exist for amigaos.

I believe there was some progress getting commodore unix (amix) running on winuae, which would need a pretty accurate emulation of the A3000 SCSI controller


Carlos Milán

Posts 95
06 Mar 2021 22:40


dj up wrote:

  However,it did continue the boot when I changed graphics to Picasso IV,but it went black screen not long after getting further into boot. After it go black I left it for a few minutes to see if it comes back,because fans on my Laptop and CPU-monitor shows FS-UAE working with heavy stuff,or got stuck in a bug,or with my setting.. Nothing happen for 5 mins,so I did not test further than that for now (I will however try on my desktop computer too,to give it some more time),but it was very interesting so far.

It doesn't make much sense that the video mode influences whatever you are able to mount your rootfs or not. Bert advice is right, configure WinUAE to use emulated devices rather than paravirtualized ones, as Linux/m68k won't have drivers for them.

Regarding the graphics part, safest bet is to use the framebuffer driver with ECS or AGA. If you get it working rightly, then you may try with the graphics card supported in this list: EXTERNAL LINK It looks like Picasso IV should be supported.

Also, there is a nice list of Amiga supported hardware here: EXTERNAL LINK 


Dj Up

Posts 37
07 Mar 2021 17:10


Thanks Bert and Carlos.

As you see I`m no Amiga expert so any info is valued as gold for me.
I am however getting the feeling that WinUAE and FS-UAE are doing a few things different. It was my understanding that most of the code for WinUAE came from FS-UAE. I have almost no experience with WinUAE compared to FS-UAE,and even in windows (old days) I tended to nerd around with the FS for windows and did find about the WinUAE later on.

In this case though,because the Debian in question had a WinUAE-config-file with it,it seems to me that I should give this a try in windows too with the version it was created for.

I am always trying to start windows as rare as possible,and that is even if I run windows 10 in a Qemu-hosted virtual machine on my server. Although with its own ssd and passed-through graphics.

I guess I must hold my breath and push "run" on it one day soon.

But before that,I`ll try pause UAE to see the rest of the messages before it goes to black.. and yes.. the fact that changing graphics made it go further does not make sense at all,even for me.


Nick Fellows

Posts 116
08 Mar 2021 20:33


About Apollo Core devs, their efforts are way better put on AROS. Linux is just a geeky thing in the Amiga :) However, if the Apollo Core truly has a PMMU, it would be nice if they publish the needed info for a kernel hacker to implement support for the native MMU in mainstream kernel.

Amen to this -Vampire is such a powerful device it lends itself to all sorts of interesting avenues to explore.


Vojin Vidanovic
(Needs Verification)
Posts 1896/ 1
08 Mar 2021 21:06


nick fellows wrote:

About Apollo Core devs, their efforts are way better put on AROS. Linux is just a geeky thing in the Amiga :)

Team has explained they have no interest in Linux. However, as you say, publishing PMMU details would surely help both AmigaOS, AROS and Linux MMU using tools.

On sidenote, Vampire is m68k powerful as never before, and thus might be suitable candidate for small comeback of m68k architecture for Linux. Finally we have nice CPU, plenty of RAM and 24 bit graphics as standard.



Steve Ferrell

Posts 403
09 Mar 2021 23:43


I honestly don't understand why anyone would want to run Linux on a Vampire even if a bootable version existed.  It would be slow as molasses at ~200 MIPS and no hardware video acceleration, not to mention that there would be no software library either.  If you really want the full-Linux experience, just buy a $25 RaspberryPi and have a blast with that.  It also makes perfect sense for the Apollo team to NOT support Linux, not only based on the hardware price-point, but from the standpoint of the developer resources they'd have to commit to supporting yet another OS.  They have their hands full supporting OS3, AROS, and to a lesser extent, Atari TOS.  A RaspberryPi literally wipes the floor with a Vampire in terms of price, performance, and software availability, so don't distract the team with Linux nonsense.  Allow them to stay focused on making the Vampire the best classic Amiga that money can buy.


Gunnar von Boehn
(Apollo Team Member)
Posts 5532
10 Mar 2021 08:46


The 68K family is maybe the world best CPU architecture for Assembler coding.
The 68K family is much more coder friendly than others.
And this coder friendliness was for sure the reason that
the Amiga and Atari scene were full of people  coding
big applications, games, and demo in pure 68k assembly.

The Amiga had a very clean and nice and elegant chipset,
which was designed to be directly coded without "layers" in between.

To me the nice assembly and the elegant chipset coding is what makes the spirit of Amiga coding.

Its obvious that Linux is absolute the opposite direction and it does neither support direct HW coding nor encourage assembly coding.



Antony Coello

Posts 124
10 Mar 2021 11:53


Gunnar von Boehn wrote:

The 68K family is maybe the world best CPU architecture for Assembler coding.
  The 68K family is much more coder friendly than others.
  And this coder friendliness was for sure the reason that
  the Amiga and Atari scene were full of people  coding
  big applications, games, and demo in pure 68k assembly.
 
  The Amiga had a very clean and nice and elegant chipset,
  which was designed to be directly coded without "layers" in between.
 
  To me the nice assembly and the elegant chipset coding is what makes the spirit of Amiga coding.
 
  Its obvious that Linux is absolute the opposite direction and it does neither support direct HW coding nor encourage assembly coding.
 

I am very happy to hear Gunnar say this and I totally agree here. I know playing with a new OS is 'fun' but going to all the effort of porting a Linux distro when the team are hard at work on an Amiga operating system designed specifically for the Amiga and able to access all the HW in a clear legible manner seems, well, counter-productive.

The Amiga has a great software base 'as is' with stuff still being made, especially with the resurgence in recent years.

However, thats my opinion; but I understand that other people like to spend their time fiddling with an OS for months, so if it makes you happy...

Also, if there was MMU logic secretly floating around, I believe it would be better used for making the V500/600 Atari ST compatible.



Roland Engelen

Posts 1
10 Mar 2021 17:00


Dear Gunnar,

I can agree with you an also not.
For sure we do Not need a Linux distribution for the Vampire. There is no reason for that and
the way you are going with the Apollo OS is exactly the right one.

But with the Assembler thing. I don't know.
I think the goal must be to get back some developers that have not done something for the Amiga for a long time and also to get some developers from other Platforms they want something to do for the Amiga.
I don't think that we get them if you tell them they have to learn Assembler.
This people need modern Libraries an easy to use language and some kind of modern IDE
Or they will not develope for the Amiga I think.
And we really need as much developers as we can get.
And everyone can still use Assembler if he wants.

And by the way very nice work you and your team has done there!

regards
Roland

 



posts 30page  1 2