[ORLinux] [OpenRISC] github repos for linux kernel and uclibc

[Peter Gavin]

I just cloned stefan's uClibc and linux repos into the github
openrisc. I just forked the uClibc repo Stefan had in his github, and
I cloned his repo at git://openrisc.net/stefan/linux onto my personal
github, then forked it from there.

You should probably ping the linux list (linux at lists.openrisc.net) about
this.

I've added that list to the CCs.

The most up-to-date Linux should be upstream... if it's not, there's
something wrong. Why aren't patches being submitted?

I know nothing about that. One problem may be that this repo hasn't been
merged with Linus's tree in some time (since 3.4).

I suppose I should have pinged the list before doing this. I picked
Stefan's primarily because it's a fork of your repo, and he's added a few
things on top of that.

I can remove this repo and we can put a different one in its place. But I
think we should keep a mirror of our newest work-in-progress kernel tree on
github with the other parts of the toolchain, that's known to work and have
the most recent fixes and features, so that new toolchain developers don't
have to wonder what repos to use when they're getting started.

My _only_ concern is that this becomes a dumping ground for stuff that
won't be (or can't be) sent upstream; Linux patches need to go via the
mailing list whence the road to the upstream kernel should be reasonably
short (if not, just let me know where you think there's a problem and
we'll see what we can do).

Yeah, we really need to make sure these repos only hold patches that can
eventually go into upstream.

One thing I'm currently working on is removing the busybox binaries from
the kernel tree (the files in linux/arch/openrisc/support/initramfs/...),
and instead build them from the busybox sources and construct the initramfs
from scratch using an external script. I've got this partly done. There's
a git repo with the script at:
https://github.com/pgavin/or1k-toolchain-build

For now (but I'm sure I'll change this at some point) the script wants all
the repositories to exist under the same path, and it only works with my my
version of or1ksim, but it builds the toolchain in 4 modes (elf & linux,
both with and without delay slots), and compiles uclibc, the kernel, and
busybox. It doesn't (yet) construct the initramfs, but that's next. There
are also some problems with compiling uClibc in no-delay-slot mode that I
need to work out.

Eventually I might try using this script as part of a build bot that will
check out the latest repos, build everything, run testsuites, and log
everything on a nice webpage so we can see what tests are failing and so
on. It will take some work, but I think will be a big help.

NB, regarding uClibc, is that the repo you've cloned contains a set of
patches that are incompatible with upstream... hopefully the whole
uclibc/Linux syscall mess will be sorted out shortly.

Yeah, I noticed that. I wasn't sure what else to do. But it's really just
there as a mirror, and can be replaced as well.

-Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openrisc.net/pipermail/linux/attachments/20121128/e4a20407/attachment.html>

[Jonas Bonn]

The most up-to-date Linux should be upstream... if it's not, there's
something wrong. Why aren't patches being submitted?
I know nothing about that. One problem may be that this repo hasn't
been merged with Linus's tree in some time (since 3.4).

See the 'for-upstream' branch...

Aside from that, Linus' repo is what you should be basing new features
on... hence, that's the repo that should be the 'openrisc' one (as
opposed to personal repos) on the main github page, in my opinion. (And
Linus' repo is already mirrored on github, so there's really no need to
do it again...)

Yeah, we really need to make sure these repos only hold patches that
can eventually go into upstream.

Perfect! As long as we stick to that rule then there shouldn't be any
confusion anywhere.

One thing I'm currently working on is removing the busybox binaries
from the kernel tree (the files in
linux/arch/openrisc/support/initramfs/...), and instead build them
from the busybox sources and construct the initramfs from scratch
using an external script. I've got this partly done. There's a git
repo with the script
at: https://github.com/pgavin/or1k-toolchain-build

Upstream kernel does not contain the initramfs bits... that's just a
crutch for openrisc people who need to boot the kernel quickly without
having to figure out how to build a userspace. Removing it is a bit of
an anti-feature... I had an idea of moving it to a submodule, though, at
some point but there are more pressing issues (real kernel bugs,
interesting that these never get reported... I just figure that nobody
actually uses Linux on openrisc :) )

For now (but I'm sure I'll change this at some point) the script wants
all the repositories to exist under the same path, and it only works
with my my version of or1ksim, but it builds the toolchain in 4 modes
(elf & linux, both with and without delay slots), and compiles uclibc,
the kernel, and busybox. It doesn't (yet) construct the initramfs,
but that's next. There are also some problems with compiling uClibc
in no-delay-slot mode that I need to work out.

There's a bunch of these scripts floating around. Mine's a Makefile and
parallelizes better than the rest... I updated it last weekend to build
Stefan's latest stuff... I should probably publish that somewhere.

Eventually I might try using this script as part of a build bot that
will check out the latest repos, build everything, run testsuites, and
log everything on a nice webpage so we can see what tests are failing
and so on. It will take some work, but I think will be a big help.

I know someone who already had most of this in place... :(

/Jonas

[Stefan Kristiansson]

Post by Jonas Bonn

The most up-to-date Linux should be upstream... if it's not, there's
something wrong. Why aren't patches being submitted?
I know nothing about that. One problem may be that this repo hasn't
been merged with Linus's tree in some time (since 3.4).

See the 'for-upstream' branch...
Aside from that, Linus' repo is what you should be basing new features
on... hence, that's the repo that should be the 'openrisc' one (as
opposed to personal repos) on the main github page, in my opinion. (And
Linus' repo is already mirrored on github, so there's really no need to
do it again...)

I agree, my tree is a 'playground tree', that has no place there,
as you said, we really don't need an 'official' openrisc Linux
tree, since there already is one, Torvalds tree.

That said, your master tree on openrisc.net has a lot of 'goodies'
that aren't upstreamed (like drivers for SPI etc), so to bounce your
question back at you, why aren't those upstreamed?
I know, I'm throwing stones in a glass house accusing you for
throwing stones in a glass house, I have stuff like that laying around as
well, consider it a bit 'tongue-in-cheek'.

But the fact remains, that's the tree that's easiest to "get going",
that's what people are most likely going to use, not Torvalds tree.

Stefan

[Jonas Bonn]

Post by Stefan Kristiansson
That said, your master tree on openrisc.net has a lot of 'goodies'
that aren't upstreamed (like drivers for SPI etc), so to bounce your
question back at you, why aren't those upstreamed?

Yes, I'm aware that there's a couple of things lingering there:

i) SPI driver is not upstreamable because the driver is not 'generic';
specifically, it relies on 'struct cpuinfo' for openrisc. The fix for
this depends on reworking OpenRISC to use the common clock framework. I
did this work about a month ago, but haven't had time to finish it off
and I think I won't push it until 3.9; but once that's done, the SPI
driver can go upstream.

ii) There's a couple of patches for the ethernet driver (ethoc): these
aren't upstream due to... sloth!

iii) What else? The rest should be initramfs stuff and that's not
going upstream.

And while we're at it, there's other stuff floating around that needs
submitting.

i) ORSoC hasn't submitted the devicetree for their dev-board despite
shipping a modified kernel for it for more than a year. I haven't
checked what other modifications they've made, but there's no reason
this stuff should not be upstream.

ii) We're missing the devicetree for AAC's OBC500.

iii) There's a bunch of common/consumer boards in use for which there's
no reason not to provide a default upstream configuration and
devicetree.

iv) ...and I know of several cores in use for which there are no
upstream drivers despite the users being "open source friendly".

Post by Stefan Kristiansson
I know, I'm throwing stones in a glass house accusing you for
throwing stones in a glass house, I have stuff like that laying around as
well, consider it a bit 'tongue-in-cheek'.

What fun are stones if you can't throw them? Fire away...!

Post by Stefan Kristiansson
But the fact remains, that's the tree that's easiest to "get going",
that's what people are most likely going to use, not Torvalds tree.

Yes, and it's "stable"... since 3.4! ;)

/Jonas

[Peter Gavin]

Post by Jonas Bonn
Aside from that, Linus' repo is what you should be basing new features
on... hence, that's the repo that should be the 'openrisc' one (as
opposed to personal repos) on the main github page, in my opinion. (And
Linus' repo is already mirrored on github, so there's really no need to
do it again...)

Ok, so it's just confusion on my part. There's some conflicting
documentation around, and it just wasn't clear to me what we should be
using as the "official" one :)

The reason I did this is that I want to add support for no-delay-slot mode.
So I'll just delete the repo I just created and fork Linus' repo in its
place so eventually I can push the changes there.

There's a bunch of these scripts floating around. Mine's a Makefile and

Post by Jonas Bonn
parallelizes better than the rest... I updated it last weekend to build
Stefan's latest stuff... I should probably publish that somewhere.

Mine will parallelize the build fairly well, as well. It's a script for
SCons, which is a dependency-base build tool like make, but it's
python-based so it's ridiculously flexible... but unfortunately harder to
learn.

I know someone who already had most of this in place... :(
Are you referring to Ruben's orbuild? I took a look at it, but I haven't
used perl in years, and digging into it to figure out where to put my
changes seemed harder than just whipping something up for scons :)

-Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openrisc.net/pipermail/linux/attachments/20121129/5e6333a7/attachment.html>

[Peter Gavin]

Post by Peter Gavin
So I'll just delete the repo I just created and fork Linus' repo in its
place so eventually I can push the changes there.

Nevermind, it seems I can create new repos, but not delete them :/

Would a kind soul who has the permissions mind deleting it for me? I'll
worry about putting a new repo up later, once I've actually got some
changes to publish.

-Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openrisc.net/pipermail/linux/attachments/20121129/48523b43/attachment.html>

[Stefan Kristiansson]

Post by Peter Gavin

Post by Peter Gavin
So I'll just delete the repo I just created and fork Linus' repo in its
place so eventually I can push the changes there.

Nevermind, it seems I can create new repos, but not delete them :/
Would a kind soul who has the permissions mind deleting it for me? I'll
worry about putting a new repo up later, once I've actually got some
changes to publish.

Done.

But it's great news that other people than 'owners' actually can create
repositories, I didn't think that was possible.
That was the intention from the start, that anybody should be able to do
that.

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openrisc.net/pipermail/linux/attachments/20121129/976a768b/attachment.html>

[Jonas Bonn]

Post by Peter Gavin
The reason I did this is that I want to add support for no-delay-slot
mode. So I'll just delete the repo I just created and fork Linus' repo
in its place so eventually I can push the changes there.

Cool... I figured as much. You know the mantra: "release early, release
often." I'd recommend pushing an early version of your work to the
mailing list because you may find I have a strong opinion of the form
that change should take... :) (...the ORLinux mailing list, so we can
spare the HW folks some pain).

Post by Peter Gavin
Mine will parallelize the build fairly well, as well. It's a script
for SCons, which is a dependency-base build tool like make, but it's
python-based so it's ridiculously flexible... but unfortunately harder
to learn.

Ah, SCons... I remember when I was convinced that was going to take over
the world! Fortunately, the next day I woke up sober! :)

Anyway, good luck with that. I agree, it should parallelize well!

/Jonas