Starting with s3c6410

Andy Green andy at
Fri Oct 3 12:00:26 CEST 2008

Hash: SHA1

Hi -

As Wolfgang told a week or two back, we will be working in future with
s3c6410 next, and we are going to need bootloader and kernel support for
it.  (Obviously since we start considering it now, this is not something
that will be usable for a long time, so please regard this as only one
step better than bluesky stuff.)

The bootloader situation is that its memory map differs from s3c2442 in
memory placement, that makes it hard but not impossible to have a common
binary for Qi that covers 2442 and 6410 the same.  Since in all cases
there is a huge storage area available compared to bootloader footprint,
it doesn't hurt to have code twice that is linked to different address
range, except care is needed about symbols then.  So we will try to
figure out keeping a single bootloader binary for both CPUs, but if it
is too hard fall back to compile-time selection and have two binaries.

For the kernel, the situation is not great as it stands.  Samsung
provide a Board Support Package (BSP) which is a big patchset with
support for the CPU, which is obviously a great deal better than
nothing.  However,

 - today it is against 2.6.21 and as we know from what happens to our
own stuff, it is bitrotting

 - the BSP structure is not the same as the mainline s3c24xx stuff done
by Ben Dooks, it won't be accepted upstream as it is

 - it puts us into a bad situation for uplevelling, we can force it up
against mainline HEAD but when they update their BSP we find we are on
an incompatible, unsupported fork

 - when 6410 is eventually done in mainline, again we find all our work
is on the now deprecated BSP basis and we would face a major crisis

After giving this some thought, Openmoko decided to fund a rewrite of
the s3c6410 BSP by Ben Dooks himself, so it is certain we will be able
to work with a mainline implementation from the start.  I went to see
him last week and we have agreed terms and a schedule and the work is

What Openmoko is funding is ENTIRE 6410 BSP rewrite into mainline, it
includes all the major units serviced by the BSP including USB OTG and
Camera units (even IDE and others we don't use ourselves), and of course
this will be available for everyone else targeting 6410 to use.  There
are already other 6410 based Linux projects that will get a big boost
from this.  It's a great example of Openmoko scratching its own itch for
the reasons above AND giving back to Linux in a major, high quality way
- -- direct into mainline.  Obviously this is great for Samsung too.

Since it is a rewrite, we won't get first usable code drop for ~6 weeks,
 the plan is we will track a git branch from Ben as he works.  (When he
is finally done, we will just be able to track upstream HEAD because it
will all be in there already.)  The first drop is scheduled to have just
enough bits to get a working userspace running from uSD card.  But, it
means we are on the right basis from the start.

A ramification from this are that we will be working against upstream
HEAD for a long time and not a release kernel version.  That is actually
interesting for us, I noticed with Jonas' patches recently he was
attracted to work on it due to stable-tracking, and the effect was
direct path upstream for his work immediately.  That's definitely
something we would like see more regularly and living on HEAD helps that.

It also means that upstream effort on stuff like pcf50633 we will likely
use again with s3c6410 are of more than academic interest...

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list