New platforms

New platforms

[Brian Murphy]

Hi,
    I have a port of linux-mips to the Lasat (later Eicon) platform(s) -
based on vr4300, vr5000 and vr4120 chips. I would very much like
to have the code incorporated in the CVS at OSS. How do I go
about this?

/Brian

Re: New platforms

[Karsten Merker]

On Wed, May 29, 2002 at 12:17:17PM +0200, Brian Murphy wrote:

>     I have a port of linux-mips to the Lasat (later Eicon) platform(s) -
> based on vr4300, vr5000 and vr4120 chips. I would very much like
> to have the code incorporated in the CVS at OSS. How do I go
> about this?

Usually by splitting your patches into small chunks (one patch for
one feature) and submitting them to Ralf Baechle (ralf@gnu.org) and/or 
to this list.

Regards,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

Re: New platforms

[James Simmons]

> Hi,
>     I have a port of linux-mips to the Lasat (later Eicon) platform(s) -
> based on vr4300, vr5000 and vr4120 chips. I would very much like
> to have the code incorporated in the CVS at OSS. How do I go
> about this?

Please at a look at the Linux MIPS project at sourceforge. We already have
several VR chipsets supported. 

http://linux-mips.sf.net

Re: New platforms

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On Wed, May 29, 2002 at 01:16:53PM -0700, James Simmons wrote:
> > Hi,
> >     I have a port of linux-mips to the Lasat (later Eicon) platform(s) -
> > based on vr4300, vr5000 and vr4120 chips. I would very much like
> > to have the code incorporated in the CVS at OSS. How do I go
> > about this?
> 
> Please at a look at the Linux MIPS project at sourceforge. We already have
> several VR chipsets supported. 

The Eicons are not anything really embedded rather than Cobalt RaQ like.

Flo
PS: I dont like this split up tree - Currently Ralf is the one 
feeding mainstream so please stop this diversification of the trees
as the normal user gets completely confused which makes linux mips
a VERY BAD target and does not help any popularity for the mips targets.
We had the linux-vr desaster before which helped nothing but in
the end bound developer efforts which were useless in the end.
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: New platforms

[James Simmons]

> PS: I dont like this split up tree - Currently Ralf is the one 
> feeding mainstream so please stop this diversification of the trees
> as the normal user gets completely confused which makes linux mips
> a VERY BAD target and does not help any popularity for the mips targets.
> We had the linux-vr desaster before which helped nothing but in
> the end bound developer efforts which were useless in the end.

True. The problem is the slow migration to Linus tree and the slow
migration into the OSS tree. Here is a suggestion, how about using the BK
tree at bkbits.net. There is a mips tree there but it has never been used. 
The question is who is the admin of that tree so we can have access ? 

Re: New platforms

[Ilya]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 30 May 2002, James Simmons wrote:
>
> > PS: I dont like this split up tree - Currently Ralf is the one
> > feeding mainstream so please stop this diversification of the trees
> > as the normal user gets completely confused which makes linux mips
> > a VERY BAD target and does not help any popularity for the mips targets.
> > We had the linux-vr desaster before which helped nothing but in
> > the end bound developer efforts which were useless in the end.
>
> True. The problem is the slow migration to Linus tree and the slow
> migration into the OSS tree.
You can always pos your patches to the list, and whatever didn't make it
into the tree, can be picked up from there by interested parties.

> Here is a suggestion, how about using the BK
> tree at bkbits.net. There is a mips tree there but it has never been used.
> The question is who is the admin of that tree so we can have access ?
Are you saing "let's make yet another tree"? Ugh...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/

iD8DBQE89qj484S94bALfyURAufLAJ9s0E5CSZllyEq4wFcTgogaBra38QCgpntH
CjYS1mv/lzI9xnTS3NspGoM=
=UBYu
-----END PGP SIGNATURE-----

Re: New platforms

[James Simmons]

> > True. The problem is the slow migration to Linus tree and the slow
> > migration into the OSS tree.
> You can always pos your patches to the list, and whatever didn't make it
> into the tree, can be picked up from there by interested parties.

Now that I have time I plan to do that.

> > Here is a suggestion, how about using the BK
> > tree at bkbits.net. There is a mips tree there but it has never been used.
> > The question is who is the admin of that tree so we can have access ?
> Are you saing "let's make yet another tree"? Ugh...

No. I'm talking about having a BK tree to use to sync up to Linus with.
This way the OSS and SF tree and push into the BK tree and have no issues.

Re: New platforms

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

On Fri, May 31, 2002 at 12:17:41PM -0700, James Simmons wrote:
> 
> No. I'm talking about having a BK tree to use to sync up to Linus with.
> This way the OSS and SF tree and push into the BK tree and have no issues.
> 

I dont know how others feel which would need to work more with this but
i don't like BK's license (and its advocat Larry 'need to earn money' McVoy).

Forcing people into creating seperate trees due to licensing issues of
the SCCS is not really something we need now.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: New platforms

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On Thu, May 30, 2002 at 03:16:10PM -0700, James Simmons wrote:
> > PS: I dont like this split up tree - Currently Ralf is the one 
> > feeding mainstream so please stop this diversification of the trees
> > as the normal user gets completely confused which makes linux mips
> > a VERY BAD target and does not help any popularity for the mips targets.
> > We had the linux-vr desaster before which helped nothing but in
> > the end bound developer efforts which were useless in the end.
> 
> True. The problem is the slow migration to Linus tree and the slow
> migration into the OSS tree. Here is a suggestion, how about using the BK
> tree at bkbits.net. There is a mips tree there but it has never been used.. 
> The question is who is the admin of that tree so we can have access ? 

Bitkeeper is evil non free software i will hopfully never be required
to use.

If the migration is to slow help Ralf - Ralf is handing out CVS access
to those he trusts developing in the correct direction. I also think
that there are ways to split up feeding back the stuff. Generating
one another tree wont help a lot.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

New platforms

[Chris Tapp]

Hi,

I've been evaluating OpenEmbedded and saw the announcement of 'Yocto'  
on the mailing list. Yocto looks like it may be better for my needs as  
it is more refined.

As there isn't currently support for the ALIX 3D3 (a Geode LX based  
system), I am interested in creating and maintaining a BSP for it.  
This should also work with other LX systems (e.g. SUMO ST166, other  
ALIX variants), some with no changes, some with minor ones.

Could you give me an idea how much work would be involved in doing  
this and what it involve?

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: New platforms

[Bruce Ashfield]

On 10-11-18 05:36 AM, Chris Tapp wrote:
> Hi,
>
> I've been evaluating OpenEmbedded and saw the announcement of 'Yocto'
> on the mailing list. Yocto looks like it may be better for my needs as
> it is more refined.
>
> As there isn't currently support for the ALIX 3D3 (a Geode LX based
> system), I am interested in creating and maintaining a BSP for it.
> This should also work with other LX systems (e.g. SUMO ST166, other
> ALIX variants), some with no changes, some with minor ones.
>
> Could you give me an idea how much work would be involved in doing
> this and what it involve?

I can answer from the kernel point of view.

The supported yocto kernel(s) (currently 2.6.34 and
shortly 2.6.37-rcX) are the place where I can assist
in getting you up and running with a new board/platform
fairly easily.

The kernel documentation is being updated (since I've
made changes recently to streamline just what you
are talking about here), but I can give some more
hands on help while those docs are still outstanding.

For the kernel, you'd need to create a machine.conf
with your optimization, features, etc, and give the
machine a name. There are obviously plenty of examples
on how to do this in the tree.

At that point, you can bootstrap the the BSP process
by doing a: bitbake -c configure linux-yocto.

You then have the kernel git repository staged and
branch for kernel changes to be added. Working with
the kernel in git is key, since you can have a
common branch, and have board specific branches for
configuration or features that are not generally
applicable to all boards.

You can iteratively configure and build the board
from this point.

When you are happy with the changes you can export
the patches, or keep the branches in a local git
tree (better), and if there is assistance in maintaining
the BSP(s) we can contribute them to the maintained
kernel repository (best). This then enables collaboration
and best practices development.

The amount of work depends on the type of kernel
patches you need to add for the board(s) and the
desired feature mix. Userspace difficulty should
be manageable if the known working ARM baseline
builds are used as starting point.

I've gone light on the details here, but if there is
interest, I can provide more information.

And again, this is speaking from the kernel point of
view only.

Cheers,

Bruce

>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: New platforms

[Tian, Kevin]

>From: Bruce Ashfield
>Sent: Tuesday, November 23, 2010 1:09 AM
>
>On 10-11-18 05:36 AM, Chris Tapp wrote:
>> Hi,
>>
>> I've been evaluating OpenEmbedded and saw the announcement of 'Yocto'
>> on the mailing list. Yocto looks like it may be better for my needs as
>> it is more refined.
>>
>> As there isn't currently support for the ALIX 3D3 (a Geode LX based
>> system), I am interested in creating and maintaining a BSP for it.
>> This should also work with other LX systems (e.g. SUMO ST166, other
>> ALIX variants), some with no changes, some with minor ones.
>>
>> Could you give me an idea how much work would be involved in doing
>> this and what it involve?

Kernel is the biggest part you'd work out which thanks to Bruce you should
have rich information below. Besides, you may also have some board specific
firmware, 3rd party components, xserver, etc.

Generally speaking, you need create a new layer which bundles all board
specific bits together which are then added on top of poky core layer.  

You can read http://www.yoctoproject.org/sites/default/files/bsp-guide_4.pdf
which has a detail description how a new BSP is created. 

You can also refer to existing layers such as meta-emenlow for reference.

On the other hand, if all the variances you care about is just in kernel side,
basically what Bruce describes is enough to create a new MACHINE. For 
example, you may refer to routerstationpro:

commit 149f2262135ca87608783a8801c9c2d978d8c8ef
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date:   Sun Oct 10 14:11:07 2010 -0400

    routerstationpro: create machine conf and compatibility

    BUGID: 422

    Add the machine configuration and kernel infrastructure for building
    the routerstation pro BSP.

    Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>

Hope above helps.

Thanks,
Kevin

>
>I can answer from the kernel point of view.
>
>The supported yocto kernel(s) (currently 2.6.34 and
>shortly 2.6.37-rcX) are the place where I can assist
>in getting you up and running with a new board/platform
>fairly easily.
>
>The kernel documentation is being updated (since I've
>made changes recently to streamline just what you
>are talking about here), but I can give some more
>hands on help while those docs are still outstanding.
>
>For the kernel, you'd need to create a machine.conf
>with your optimization, features, etc, and give the
>machine a name. There are obviously plenty of examples
>on how to do this in the tree.
>
>At that point, you can bootstrap the the BSP process
>by doing a: bitbake -c configure linux-yocto.
>
>You then have the kernel git repository staged and
>branch for kernel changes to be added. Working with
>the kernel in git is key, since you can have a
>common branch, and have board specific branches for
>configuration or features that are not generally
>applicable to all boards.
>
>You can iteratively configure and build the board
>from this point.
>
>When you are happy with the changes you can export
>the patches, or keep the branches in a local git
>tree (better), and if there is assistance in maintaining
>the BSP(s) we can contribute them to the maintained
>kernel repository (best). This then enables collaboration
>and best practices development.
>
>The amount of work depends on the type of kernel
>patches you need to add for the board(s) and the
>desired feature mix. Userspace difficulty should
>be manageable if the known working ARM baseline
>builds are used as starting point.
>
>I've gone light on the details here, but if there is
>interest, I can provide more information.
>
>And again, this is speaking from the kernel point of
>view only.
>
>Cheers,
>
>Bruce
>
>>
>> Chris Tapp
>>
>> opensource@keylevel.com
>> www.keylevel.com
>>
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

Re: New platforms

[Tom Zanussi]

On Thu, 2010-11-18 at 02:36 -0800, Chris Tapp wrote:
> Hi,
> 
> I've been evaluating OpenEmbedded and saw the announcement of 'Yocto'  
> on the mailing list. Yocto looks like it may be better for my needs as  
> it is more refined.
> 
> As there isn't currently support for the ALIX 3D3 (a Geode LX based  
> system), I am interested in creating and maintaining a BSP for it.  
> This should also work with other LX systems (e.g. SUMO ST166, other  
> ALIX variants), some with no changes, some with minor ones.
> 
> Could you give me an idea how much work would be involved in doing  
> this and what it involve?
> 

I can give you a bit of an idea from a practical standpoint, since I've
also started working on a BSP for a new board just recently (i.e. I'm
actually still on the learning curve myself, hopefully anyone who knows
better will correct any of errors or misconceptions...)

As mentioned by Bruce, things have changed lately as far as
bootstrapping a board - it should be easier now, but something like the
below should work to get you started.

As also mentioned by Bruce, you need a machine.conf that describes your
machine - there are a bunch of examples to start from, in a couple of
places, a bunch in in meta/conf/machine and another example that's part
of its own layer, in meta-emenlow/conf/machine.

The most recently up-to-date machines that are probably more similar to
yours and that you might want to look at are
meta/conf/machine/atom-pc.conf and
meta-emenlow/conf/machine/emenlow.conf.  Both of these were either just
added or upgraded to use the yocto kernel
(http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/).  The main
difference between them is that the emenlow is in its own layer, because
it needs some extra machine-specific packages such as its own video
driver and supporting packages, etc.  The atom-pc is simpler and doesn't
need any special packages - everything it needs can be specified in
the .conf file.  Note also that this one machine (atom-pc) supports all
of Asus eee901, Acer Aspire One, Toshiba NB305, and Intel BlackSand with
no changes.  If you wanted to make minor changes to support a slightly
different machine, you could create a new .conf for it and add it
alongside the others (maybe keeping the common stuff separate and
including it).  Similarly, you can also use multiple .confs for
different machines even if you do it as a separate layer like
meta-emenlow.

So anyway, for my new layer, meta-crownbay, I basically made a copy of
meta-emenlow and fixed it up/removed anything I didn't need - in
meta-crownbay/recipes, the only thing left was the kernel dir with a
linux-yocto_git.bbappend file in it (linux-yocto is the kernel listed in
meta-crownbay/conf/machine/crownbay.conf).  I added a new entry to
build/conf/bblayers.conf so the new layer can be found by bitbake.

So to get things working, the main thing to start out with is to get an
image with a working kernel built.  For the kernel to compile
successfully, you need to create a branch in the git repo specifically
named for your machine.  So first create a bare clone of the windriver
git repository, and then create a local clone of that:

$ git clone --bare git://git.pokylinux.org/linux-2.6-windriver.git linux-2.6-windriver.git
$ git clone linux-2.6-windriver.git linux-2.6-windriver

Now create a branch in the local clone and push it to the bare clone:

$ git checkout -b crownbay-standard origin/standard
$ git push origin crownbay-standard:crownbay-standard

At this point, your git tree should be set up well enough to compile,
now you just need to point the build at the new kernel git tree, by
commenting out the SRC_URI in
meta/recipes-kernel/linux/linux-yocto_git.bb and using a SRC_URI that
points to your new bare git tree (you should also be able to add this in
the do this in the linux-yocto_git.bbappend in the layer):

# To use a staged, on-disk bare clone of a Wind River Kernel, use a 
# variant of the below
# SRC_URI = "git://///path/to/kernel/default_kernel.git;fullclone=1"
SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
           git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"

After doing that, and selecting the machine in build/conf/local.conf
e.g.

MACHINE ?= "crownbay"

you should be able to build and boot an image with the new kernel (e.g.
bitbake poky-image-sato-live).

Of course, that will give you a kernel with the default config, which is
probably not what you want.  If you just want to set some kernel config
options, you can do that by putting them in a files, say some.cfg
containing:

CONFIG_NETDEV_1000=y
CONFIG_E1000E=y

and some other.cfg containing

CONFIG_LOG_BUF_SHIFT=18

http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/

SRC_URI_append_crownbay = " file://some.cfg \
                            file://other.cfg \
                          "

You could also add these directly to the git repo's wrs_meta branch as
well, but this is probably easier.

If you're also adding patches to the kernel, you can do the same thing,
and put your patches in the SRC_URI as well (plus .cfg for their kernel
config options if needed).

Practically speaking, to generate the patches, you'd go to the source in
the build tree, for example,

build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+
0431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux

and modify the code there, using quilt to save the changes, and
recompile (bitbake -c compile -f) until it works.  Once you have the
final patch from quilt, copy it to the SRC_URI location, and it should
be applied the next time you do a clean build.  Of course, since you
have a branch for the BSP in git, it would be better to put it there
instead e.g. in my case, commit the patch to the crownbay-standard
branch, and next build it will be applied from there.

I know some of the above is the old way of doing things, and I'm sure
other could offer a more efficient development cycle, but that's what
I'm currently using and it works for me for now.

This is only some basic practical stuff to help get started - you really
want to look at the Poky Reference Manual for much more useful info on
actually what things in the recipes actually mean, etc.:

http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html

One section of that is a 'BSP guide' which is available separately here:

http://www.yoctoproject.org/sites/default/files/bsp-guide_2.pdf

We'd really like to expand that with whatever additional info might be
useful to BSP developers, so please let us know if you have suggestions.

Thanks,

Tom

> Chris Tapp
> 
> opensource@keylevel.com
> www.keylevel.com
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto