On Thu, Feb 12, 2015 at 09:46:57AM +0530, Saket Sinha via illumos-discuss wrote:
...
> > The challenge with this project at this time, is that's all about early
> > bring up. We haven't even gotten to the point where the main kernel
> > virtual memory subsystems have been started. That means, that you have
> > the opportunity to learn quite a lot; however, you have to be really
> > *quite* driven. Bring up projects are the kind of projects that
> > basically continuously punch you in the gut, giving you quite hard,
> > nigh-undebuggable problems, and due to where you are early in boot,
> > don't give you the tools to find them. There's no kernel debugger, until
> > someone writes support for it.
>
> I have had the same experiences. I have spent quite some time with bringing
> up boards on Linux and bare-metal programming.
That's good. I just want to make a distinction that's quite important to
the Raspberry Pi bringup effort. When people hear "Raspberry Pi bringup"
they think one of two things:
(1) we *lack* ARM support, we need to implement all the ARM and Raspberry Pi
specific support code
(2) we *have* ARM support, we just need to get the Raspberry Pi specific code
We are very solidly in #1. This means we run into some very major problems
that block just about all the other development for weeks. For example,
about two weeks ago, I ran into an issue where mutex_enter on my Pi fails.
Specifically, the strex instruction returns 1 (but it still stores the
value in memory!). At this point (having invested about 60 hours into
debugging this) I have a vague idea that it's somehow related to the way we
set up the page tables. (Even though we seem to set them up the same way
FreeBSD does.) Anyway, the point is that this was a two week detour. Since
GSOC projects are about 10 weeks in length, this sort of detour would
totally invalidate any sort of GSOC schedule. This is why Robert and I are
concerned that Raspberry Pi bringup may not be the best project for GSOC.
...
> > So, if I was going to mentor someone on this, I'd want them to already
> > have a lot of experience with building illumos and understanding how to
> > use the system. Having existing familiarity with mdb and dis are going
> > to be quite useful, or prior experience with the ARM architecture and
> > things like how the the Harvard L1 instruction and data caches work,
> > etc. These may be things you're quite familiar with, if so, that would
> > be great!
>
> I have had the experience of building Illumos both on Smart-OS and
> OpenIndiana.
Very good. I think it would put our minds at ease if you tried to build the
current ARM code we have, boot it, and tried to implement/fix something.
This will give you a better idea how much is done (very little), how much
needs to be done (a lot), and the kind of bringup work this effort entails.
Now that I think about it some more, it might even be a good way to figure
out which part of the bringup you'd be most interested in since there's no
way a single person can complete the whole thing during a summer.
How does this sound?
Jeff.
--
I abhor a system designed for the "user", if that word is a coded pejorative
meaning "stupid and unsophisticated."
- Ken Thompson
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
