Porting Minix to Raspberry Pi

[Mike Kelley]

Hi, all.

I asked this in FreeNode yesterday, but I wanted to cover all bases, so I'm asking here as well:

Is anyone currently working on porting Minix for Raspberry Pi? If not, I am considering working on it. But if someone is already working on it, it makes more sense to plug into an existing project than to start an entirely new one.

Thanks,

Mike

[Roc Vallès]

Hi Mike,

I've been meaning to look into this, but been blocked (and will still be for some weeks) because of not having a proper computer setup to do development with (moved recently).

If you do any work, be sure to keep us updated; I wouldn't want to duplicate any work.

Kind Regards,
Roc Vallès Domènech

[Mike Kelley]

Hi, Roc.

I will definitely keep the group updated on any progress on this front. My first task has been to create a script to convert K&R functions to ANSI. This is nearly complete. Once I've tested it on my local tree, I will submit it to the group for review. I am not doing any other work until that is complete, because I think it will be better to start with 100% ANSI code.

Thanks,

Mike

[Mikal "Meeh"]

Hi,

I got several of Raspberry Pi's and have started looking on this, unfortunately my time is somewhat limited. But from time to time I use some time to try figure out exact the tasklist of what's needed to be implemented. If someone wants to help it's great! I've scripted for 10 years, used C/C++ and some assembly hacking the past 3-4years, but when it comes to hardware I'm still real fresh. But at least I'll try :)

I will probably try do the same to the Banana Pi chip when I got it delivered. If those project ever get a success, I will try port minix to MIPS 24KEc V5.0 (ramips) on a MediaTek MT7620n chip I think it is. But that's way out of my league as of now, I still need to learn a lot :)

You'll find me as "Meeh" on Freenode if you want to have a chat.

Best regards,

Mikal Villa

[Mikal "Meeh"]

Haha, talking about it and got my Banana Pi in the mail today :) hacking evening!

/Mikal

[Khalifa Rouis]

Has anyone devised some kind of roadmap or a todo list in order to port Minix to RPI ?

Kind Regards,

Khalifa

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Kelley]

Hi, Khalifa.

I haven't created a formal process yet. I don't know if anyone else has either. I am working on a rough plan, though, as follows:

1. fix K&R issues. I have a script written for this. I am currently in the process of testing and refining it, I hope to post it to the group next week.

2. create / port assembly code. I have not started on this yet, but it will be a necessary step

I don't have any other concrete steps outlined yet, because this will be the first time I've ported an OS from one hardware set to another. Once I finish the K&R fix, I plan to dive into the raspian assembly code. That should provide a good example for step two.

I also plan to spend some time researching how other operating systems were ported to the RPi. that should provide a good set of guidelines for Minix3. Of course, everything will have to be tailored, but that should provide a high level view of the process.

Thanks,

mike

[Jean-Baptiste Boric]

Hi,

I didn't actually tried to port an OS (yet), but here's my two cents :

I haven't studied that specifically, but I do not expect you'll need to do huge amounts of assembly programming, since the Beagleboard port already uses an ARM processor. You should be able to use it as a starting point (however, since the Beagleboard doesn't use the same processor as the Raspberry Pi, you may need to do some modifications to the ASM code).

What you'll really need is writing/hacking a tty driver using a serial line. This is going to be your only way of interacting with Minix on the Raspberry Pi until you have Ethernet (or USB+Framebuffer) working.

[David]

Hi

Just curious, what is the current status of the porting to rpi for minix3?

the only thing I found is this: https://github.com/aunali1/Minix3-RPI

but I would like to hear feedbacks to any existing experiments, if there is any?

[Jean-Baptiste Boric]

but I would like to hear feedbacks to any existing experiments, if there is any?

I gave it a try some time ago.

I added support for board detection, RPi's UART and fixed a few ARMv7 assumptions. I stopped when I couldn't figure out how to stop the NetBSD build system from telling the compiler to generate ARMv7 instructions (the original Raspberry Pi packs a ARMv6 core) and also because I had more urging functionality to merge upstream first.

It didn't went far, but looks like it's more advanced than what's in the Git repository you mentioned. I probably still have my source code attempt stored somewhere.

[Mike Kelley]

Hi, David.

Not long after I started that project, the Raspberry Pi Foundation announced the Type 2, which has the same processor as the BeagleBone. Minix has already been ported to that processor, so I pretty much abandoned the effort. Shortly after that, my work shifted direction as well, so that double sealed it for me. I've not done anything with it.

Thanks,

Mike

--
You received this message because you are subscribed to a topic in the Google Groups "minix3" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/minix3/J8x13XgNE88/unsubscribe.
To unsubscribe from this group and all its topics, send an email to minix3+un...@googlegroups.com.

[David Liu]

I just started playing with minix very recently, I am not sure yet how deep I would go with it depending on my schedule, but it'd be nice to have something to start with regarding poring to RPi2, even it is far from complete. Meanwhile, I guess there'd be much to refer to BeagleBone porting since they share the same processor.

[Jean-Baptiste Boric]

but it'd be nice to have something to start with regarding poring to RPi2, even it is far from complete. Meanwhile, I guess there'd be much to refer to BeagleBone porting since they share the same processor.

From what I've seen, the only thing that noticeably changed is indeed the ARM processor and the peripheral base address. I could upload my aborted Raspberry Pi 1 branch so you can take the UART BSP code (basically step 1 of porting to a new board), but I was more concerned about getting serial output one way or another than writing proper, correct and clean code.

Also, it'll be useful only if you have the means to connect to a 3.3v TTL serial line. If you don't, a USB-to-serial 3.3v TTL adapter is the easiest (but not cheapest) way to achieve this.

I'll go check if I still have the source code for this.

[Jean-Baptiste Boric]

It's up at https://github.com/boricj/minix/tree/rpi.

That tree is outdated and probably botched beyond repair, but the UART support in the BSP is here and should work (in minix/kernel/arch/earm/bsp/rpi). Just remember, if you're porting to the Raspberry Pi 2 you have to change BCM2835_GPIO_BASE to the new peripheral base address beforehand.

[NovaCaine]

Hi David,

Somewhere year ago I made attempt to bring up Minix 3.3.0 (the one embedded into NetBsd infrastructure) on old Rasperry pi B+ (armv6). I enabled compiler support to ARMv6 version, bootloader support (u-boot), serial support to communicate with the board, times, interrupt controller. System was able to start on RPI+ board. able to run few seconds, but somehow failing with MMU unit (VM had persistently aborts on translation pagetables) and I gave up. If you or someone is interested of this, I can share the modifications (if I find it somewhere).

regards

Nova

[Roc Vallès]

Hi Nova,

Just to make sure... you did set the control registers to enable the new (ARMv6+) pagetable format, did you?

Roc.

[Jean-Baptiste Boric]

I enabled compiler support to ARMv6 version, bootloader support (u-boot), serial support to communicate with the board, times, interrupt controller.

Looks like this is the closest anyone ever got to a port.

Can you upload this to GitHub or somewhere else ? It'd be a shame to lose this...

[NovaCaine]

Hi Jean,

Sure. Let me find this in my archives and cleanup a bit the code changes I did. I'll get back to you in couple of days (will try to find a bit spare time at this weekend).

regards

Nova

[NovaCaine]

Hi Jean,

Here I uploaded the version I was talking about: https://github.com/NovaMinix3/rpi_b

If you, or someone else has enough power to solve the issue with MMU, will be great. I would be excited to continue further development when this problem will be jump over.

regards

Nova

[Jesse Osiecki]

Nova,

I just downloaded your code and am going to take a swing at the MMU. If you have any more changes you made since 11/15 please push them

[NovaCaine]

Hi Jesse,

I already uploaded latest changes (thanks for help from Peter Welch). Made small step forward, but still lot of stuff to do (MMU issue still unresolved). Let us know if you get some progress on it. Good luck.

regards

Nova

[Mark Pauley]

https://github.com/0xabu/qemu/

That is a great port of qemu including raspi (v1 and v2) emulation support.  I've been using it to cut my bare metal chops for raspi. Getting a GDB session up on qemu would probably be a great way to debug tricky MMU issues.  In fact, I'll try your latest master now on qemu.

-Pauley

[Mark Pauley]

I've run into trouble building the raspi_b port.  I'm in the process of merging this to current minix TOT.  Here goes nothing...

-Pauley

[Jean-Baptiste Boric]

I've run into trouble building the raspi_b port.  I'm in the process of merging this to current minix TOT.  Here goes nothing...

At the moment minix-current doesn't seem to work on ARM : https://github.com/Stichting-MINIX-Research-Foundation/minix/issues/104.

The latest known commit working on ARM seems to be 8933525 "Fix default partition in clientctl.".

[Mark Pauley]

Has anyone considered some build / test automation for MINIX in order to make sure that the multiple architectures MINIX will support in the near future won’t be broken when you merge PullRequests?

-Pauley

[Thomas Cort]

> Has anyone considered some build / test automation for MINIX 

Yes. There is a code review system that's hooked into Jenkins and does cross platform builds for every commit. You can check it out at the following URL: http://gerrit.minix3.org/

It does do a quick boot of the compiled code in an emulator. For the ARM port it uses QEMU's BealgeBoard-xM emulation, which is apparently working ( see the end of this log: http://jenkins.minix3.org/job/precommit-vm-arm-cross/508/console )

--

You received this message because you are subscribed to the Google Groups "minix3" group.

To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.

[Jean-Baptiste Boric]

Has anyone considered some build / test automation for MINIX in order to make sure that the multiple architectures MINIX will support in the near future won’t be broken when you merge PullRequests?

Gerrit and Jenkins are used for that : http://gerrit.minix3.org

Four builds are started for each commit, ARM/i386 and debug/no debug. The images are then run on virtual machines to make sure they boot, but looks like there's no tests for running on physical machines...

[Mark Pauley]

I'm running into issues with the machine-specific floating point flags in libm and libc. I believe this can be worked around with the right combination of compiler args. The ones I usually use for raspi_1 compiling are:

-mfloat-abi=hard -mfpu=vfp -march=armv6zk -mtune=arm1176jzf-s

It would appear that some of the libraries in libc and libm rely upon the hard floating point ABI (args passed in floating point registers), such as lrint.S etc.

I tried setting COPTS on the command line and something is printing nonsense into the assembler's flags:
"
--- crtbeginS.o ---
Assembler messages:
Error: can't open {!mfpu=*:-mfpu=vfpv3-d16} for reading: No such file or directory
"

However, this leads me to a deeper question: what is the plan for not just CPU architecture splitting, but for board splitting as well? I see that we have the arch/foo setup, but we'll need to call out raspi directly, _and_ we'll need to hint whether we're on a raspi_1, raspi_2 or raspi_3. _1 and _2 have a different peripheral MMIO offset (0x20000000 for _1 and 0x3F000000 for _2).

Is there a wiki we could use to discuss the process of a Raspberry Pi port? Did anyone document what they did to hack Minix 3 onto the BeagleBone series of processors?

Someone is going to have to write a mailbox driver, and use that to provide a lot of the information I believe the BeagleBone provided more straightforwardly.

[Thomas Cort]

> However, this leads me to a deeper question: what is the plan for not just CPU architecture splitting, but for board splitting as well?

We have some board splitting already. See minix/include/minix/board.h The detection happens in minix/kernel/arch/earm/pre_init.c (well, it really just grabs whatever was passed via u-boot -- u-boot does some detection on its own). The BeagleBone and BeagleBoard-xM have different but similar SoCs with different register offsets. You can see how it's handled in the kernel serial driver for example: minix/kernel/arch/earm/bsp/ti/omap_serial.c

To see what's needed to add a new board for an existing CPU, take a look at my BeagleBone Green patches: https://github.com/tcort/minix/commits/bbg

What we have now is pretty basic. There's a lot more that could be developed to make these things easier -- for example we don't have anything like Linux device tree.

TC

--

You received this message because you are subscribed to the Google Groups "minix3" group.

To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.

[Mark Pauley]

Ok, update:  I'm stuck.  I can't get Minix to compile properly and I don't fully understand where the compilation settings live.

It looks like I need some guidance from someone who knows how to configure Minix and the BSD / Toolchain properly.

1) It would appear that I need to make sure to set the CFLAGS (COPTS) properly for the raspberry pi.  Different versions of the Raspberry Pi have wildly different architectures, so we probably need to set each up as separate targets.  This shouldn't be so bad: there are only three so far. 

2) My compile fails during the libobjc build at some header failing to find pthread.h.  It seems like we need to force passing of --enable-threads=single or --disable-threads to all of the gcc sub-target configure invocations.  Or maybe I'm just doing something wrong?

My questions: Where are we controlling the default COPTS settings per ARCH? 

We want armv6hf to be the architecture, correct? We need the following flags to be passed (for RPI_1): -mfloat-abi=hard -mfpu=vfp -march=armv6zk -mtune=arm1176jzf-s

This suggests that we want to not make the soft-float stuff, and shoot for the hard float ABI.  All modern ARM processors will be using at least the VFP / Hard Float anyhow.  Most of the nice new ones (like Raspberry Pi 2 and 3) will support NEON which is a huge boon for memory throughput.  I see some comments in a few of the minix.h config files in the BSD directories about how hardware float ABI causes nasty issues right now in the ARM kernel.

Also: Where are we controlling the configure options passed to gcc and friends (libgcc / libc++ / libobjc)?

Like I said above, we need to use single threading, not posix.

thanks!

[Sambuc Lionel]

> On 4 avr. 2016, at 18:31, Mark Pauley <pau...@unsaturated.net> wrote:
>
> Ok, update: I'm stuck. I can't get Minix to compile properly and I don't fully understand where the compilation settings live.
>
> It looks like I need some guidance from someone who knows how to configure Minix and the BSD / Toolchain properly.
>
> 1) It would appear that I need to make sure to set the CFLAGS (COPTS) properly for the raspberry pi. Different versions of the Raspberry Pi have wildly different architectures, so we probably need to set each up as separate targets. This shouldn't be so bad: there are only three so far.

For development purposes, you can set those by either:
1) Exporting them in the environment, they *should* be taken correctly in consideration.
2) You can set it in share/mk/bsd.own.mk, near the top, in the
.if defined(__MINIX) # section simply by adding
CFLAGS+= -mfloat-abi=hard -mfpu=vfp -march=armv6zk -mtune=arm1176jzf-s

For the hardfloat issue, see below.

>
> 2) My compile fails during the libobjc build at some header failing to find pthread.h. It seems like we need to force passing of --enable-threads=single or --disable-threads to all of the gcc sub-target configure invocations. Or maybe I'm just doing something wrong?

That is expected, there is no pthread support on MINIX per se.

>
> My questions: Where are we controlling the default COPTS settings per ARCH?
> We want armv6hf to be the architecture, correct? We need the following flags to be passed (for RPI_1): -mfloat-abi=hard -mfpu=vfp -march=armv6zk -mtune=arm1176jzf-s
> This suggests that we want to not make the soft-float stuff, and shoot for the hard float ABI. All modern ARM processors will be using at least the VFP / Hard Float anyhow. Most of the nice new ones (like Raspberry Pi 2 and 3) will support NEON which is a huge boon for memory throughput. I see some comments in a few of the minix.h config files in the BSD directories about how hardware float ABI causes nasty issues right now in the ARM kernel.

Personally, I would say "yes! go for hardfloat VFP", sadly this requires some kernel support which has not been written yet. Most of the handling is there, as we do support this on intel, this is only some low level functions which needs to be written to do the save/restore when needed.

To implement that, the best would be to do it on one of the beagle first, and when this works you know your are safe on the rpi.

If you want to go forward first we your port, I think the best is to aime for soft-float for now.

>
> Also: Where are we controlling the configure options passed to gcc and friends (libgcc / libc++ / libobjc)?
> Like I said above, we need to use single threading, not posix.

This is done implicitly through the target definition. This definition exists within gcc only for earmv7 currently. I don't think you will need a lot of changes to get it working for earmv6. you can take a look at external/gpl3/gcc/patches and external/gpl3/gcc/files for the modifications we currently have to get support for MINIX. The default CPU is also fixed there.

I hope this helps!

Regards,

Lionel

> thanks!
>
> On Tuesday, March 22, 2016 at 9:04:30 PM UTC-7, Thomas Cort wrote:
> > However, this leads me to a deeper question: what is the plan for not just CPU architecture splitting, but for board splitting as well?
>

> We have some board splitting already. See minix/include/minix/board.h The detection happens in minix/kernel/arch/earm/pre_init.c(well, it really just grabs whatever was passed via u-boot -- u-boot does some detection on its own). The BeagleBone and BeagleBoard-xM have different but similar SoCs with different register offsets. You can see how it's handled in the kernel serial driver for example: minix/kernel/arch/earm/bsp/ti/omap_serial.c

[Mark Pauley]

This helps quite a bit Lionel.  Thanks.

I’ll try to stick with the soft-float for now as you say (so earmv6 instead of earmv6hf).

-Pauley

You received this message because you are subscribed to a topic in the Google Groups "minix3" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/minix3/J8x13XgNE88/unsubscribe.
To unsubscribe from this group and all its topics, send an email to minix3+un...@googlegroups.com.

[Mark Pauley]

10:36 PM (3 minutes ago)

Ok: I've pulled back from earmv6hf to earmv6, and I get stuck on roughly the same thing:  Minix is still not explicitly disabling pthreads.  I get the error:

In file included from minix/src/external/gpl3/gcc/dist/libobjc/../libgcc/gthr.h:148:0,

                 from minix/src/external/gpl3/gcc/dist/libobjc/thr.c:42:

./gthr-default.h:35:21: fatal error: pthread.h: No such file or directory

 #include <pthread.h>

                     ^

compilation terminated.

Do you happen to remember what the trick is to properly turn pthreads off in libgcc and friends?

-Pauley

[Mark Pauley]

Now that I think about it, maybe the problem is that I'm building these libs at all (libobjc, libgcc, libcxx).  They aren't being built for i386.  I'll check with the beaglebone build...