Raspberry Pi port proof-of-concept

[boricj]

This is a proof-of-concept port of MINIX 3 to the Raspberry Pi 2 and 3. It provides tty, fb and gpio drivers.

Being a proof-of-concept, there are lots of stupid things that should be ironed out, such as :

• To retain compatibility with QEMU's official and severely lacking Raspberry Pi emulation, the clock used is the least suitable one for this purpose and it doesn't tick at the correct real-time speed on the real hardware ;
• In the same manner, U-Boot can't boot on QEMU so a simple bootloader written in assembly unpacks the modules before jumping into the kernel ;
• To be able to build the Raspberry Pi and BeagleBoard port from the same source tree, the BSP_NAME hack merely direct each board family to its own obj directory, a side effect is that the toolchain isn't shared ;
• gpio and the kernel itself are reasonably in good shape, the rest of the drivers are just good enough to work just barely ;
• The current root file system is the initial boot ramdisk as there is no mass storage driver neither proper ramdisk support as with x86_ramdisk.sh ;
• ...

Note that this will boot on QEMU but not on the real hardware, possibly due to issue #104. A version that works on real hardware is available at the rpi3 branch in my repo (boricj/minix@2febd7e25).

Since this is a group effort and trying to attribute only one author to each commit is not possible, I used the OpenStack convention of Co-Authored-By as there is no official guideline for MINIX in this matter.

[dcvmoole]

I think I can speak for everyone that we would really love to merge this; on the other hand I'm a bit hesitant to merge code that's already known not to work right now. Is it okay with you if we defer merging this at least until after issue #104 has been fixed? For the moment there are no patches that conflict with this work, so I think the chance of it "rotting" in the meantime is quite small, but I'll keep an eye out anyway.

As a sidenote, since this is collaborative (university?) work, I feel compelled to ask explicitly just to make sure: these are in fact BSD-licensed changes, right? Sometimes institutions have weird policies about this..

[boricj]

I think I can speak for everyone that we would really love to merge this

You'll have second thoughts once you take a look at the patches :-)

on the other hand I'm a bit hesitant to merge code that's already known not to work right now.

Come to think of it, now I can't even remember if this branch indeed doesn't work on the real hardware or not. I'll give it a try just to be sure.

Is it okay with you if we defer merging this at least until after issue #104 has been fixed?

No problem.

As a sidenote, since this is collaborative (university?) work, I feel compelled to ask explicitly just to make sure: these are in fact BSD-licensed changes, right? Sometimes institutions have weird policies about this..

Short answer : it's BSD-licensed.

Long answer : the subject was explicitly filed under the contribution to an open-source project category. In previous years there were successful contributions to Git and Firefox in that category, so there's precedent here. This patch set was authored exclusively by the three of us, there's absolutely no code whatsoever owned by or derived from the teachers or the university. Pretty sure it's okay.

[dcvmoole]

You'll have second thoughts once you take a look at the patches :-)

I.. hope not? Humm :(

Pretty sure it's okay.

Good enough for me, thanks for confirming!

[boricj]

I.. hope not? Humm :(

It's not that bad. The source code itself is reasonably clean for a first try, but there is some questionable stuff in there. I'm mostly thinking about the bootloader written entirely in assembly and especially what I did to make both ports co-exist in the same source tree.

The second one is in my opinion quite nasty since I'm basically doing OBJ=../obj.${ARCH}-${BSP_NAME}. There's simply no other way right now to have more than one board vendor inside a processor family, even though ideally only the kernel should be different for each board vendor.

[boricj]

I just built this branch and gave it a try on my Raspberry Pi 2.

It works. That's... odd. Looks like #104 doesn't prevent my port from working, at least.

[sambuc]

I have been working on #104, but trying to compile with clang instead of
GCC as I couldn't figure that one out.

There I had the same issues until I realized that even in -O0 clang uses
the floating point unit to vectorize some operations, using by default the
hard float instructions & ABI.

My hunch is that GCC does something similar, as on ARMv7-a, those
instructions are guaranteed to be available. The only issue is that on ARM,
MINIX3 doesn't save/restore the FPU registers yet. All the logic is there,
as this is done on x86, but the low-level handling has not yet been
implemented for ARM.

AFAIK, on ARMv6 CPUs the FPU is optional, so maybe you got saved by that.
Again just a gut feeling, I am currently validating for GCC.

Kind regards,

Lionel

On 29 June 2016 at 17:46, Jean-Baptiste Boric notifications@github.com
wrote:

I just built this branch and gave it a try on my Raspberry Pi 2.

It works. That's... odd. Looks like #104
#104
doesn't prevent my port from working, at least.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#134 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACL7T7D3TX6A6TvJRebaFtQj54jOi71Xks5qQpNOgaJpZM4IrVHb
.

[boricj]

AFAIK, on ARMv6 CPUs the FPU is optional, so maybe you got saved by that.

The port targets ARMv7 (the original Raspberry Pi isn't supported) and we're reusing the existing toolchain as-is. Just about the only thing worthy of note is that we're not using U-Boot, we're booting straight from bare metal with whatever's environment the firmware has set up for us.

[stux2000]

Now that issue #104 has been resolved, I'd like to try to bring this pull request back into the forefront. More specifically, these changes most likely have been supplanted by the GSO Work by nekorobov. Although not 100% complete, that fork should be merged into mainline before it suffers bit-rot.

[boricj]

Yes, this pull request is superseded by nekoborov's work. It's been a long time, but I recall there are a couple of issues that prevents this work from being merged. I can't precisely recall what those issues are right now though, but it probably mostly revolves around the source tree having trouble handling more than one ARM port.

Finding enough free time for large-scale projects has been an issue for me since I left university, which is why I haven't touched MINIX3 in a long time. I'll see what I can do, but it might need to wait until May.

[stux2000]

Thanks for your informative response boric! I didn't realize there was such a significant problem surrounding that fork. I can totally relate to not having time to projects due to work and real life. :( All things considered, waiting until May/summer isn't too big of a deal. I hope you're able to have enough free time to look into it around then. Thanks again!