Adding support for our

Adding support for our

[Alex Raimondi]

Hi, 

We have a new AVR32 based embedded linux board (www.miromico.com/hammerhead), which is available now. 
We would like to use OpenEmbedded as our major build system to allow our customers to build their u-boot, 
kernel and rootfs. 
Of course we would like to contribute to oe, as well. 

Is there such a thing as a board maintainer in oe? If yes, how can we become one?

We allready adapted a few bb files to get oe building our u-boot and kernel. Should we push out these changes? 
How?

We have two developers working at this project. Our board is AVR32 based. So, if oe is our major build system we would have to take care that avr32 allway builds. This means testing, fixing, extending support. I hope this would be benefit enough to endure our newbie questions while we are getting known with the build system.

Alex

Re: Adding support for our

[Robert Schuster]

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

Hi Alexm

Alex Raimondi schrieb:
> We have a new AVR32 based embedded linux board (www.miromico.com/hammerhead), which is available now. 
That is a nice little board you have there. I personally like the AVR32
architecture. Atmel also has the better policy when it comes to
specifications. So I really like to see more AVR32 being used. :)

> We would like to use OpenEmbedded as our major build system to allow our customers to build their u-boot, 
> kernel and rootfs.
Great stuff. OE already supports the ATNGW100 (have one here) and the
AT32STK1000. If your board can boot with the same linux 2.6.24 (or with
patches to that) it will be quite easy to support your device.

> Of course we would like to contribute to oe, as well. 
Very nice!

> Is there such a thing as a board maintainer in oe? If yes, how can we become one?
We have a "MAINTAINERS" file. If you are a contributor you can add
information about the machines you are maintaining. This mainly means
that people will ask you when stuff breaks. In theory it should also
mean that people will ask you *first* if things are changed in OE that
affect your device but AFAIK we have no strict policies regarding this.

> We allready adapted a few bb files to get oe building our u-boot and kernel. Should we push out these changes? 
> How?
Open a bug report.

> We have two developers working at this project. Our board is AVR32 based.
 So, if oe is our major build system we would have to take care that
avr32 allway builds.
 This means testing, fixing, extending support. I hope this would be
benefit enough to endure our newbie questions
 while we are getting known with the build system.
OE has a very steep learning curve but when you managed it you will
benefit very much from its great flexibility.

Thanks for supporting our project!

Regards
Robert




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Adding support for our

[Cliff Brake]

On Fri, Oct 17, 2008 at 1:42 AM, Alex Raimondi <mailinglist@miromico.ch> wrote:
> Hi,
>
> We have a new AVR32 based embedded linux board (www.miromico.com/hammerhead), which is available now.
> We would like to use OpenEmbedded as our major build system to allow our customers to build their u-boot,
> kernel and rootfs.
> Of course we would like to contribute to oe, as well.

Great, welcome to the project.

> Is there such a thing as a board maintainer in oe? If yes, how can we become one?

Yes, see MAINTAINERS in the root OE directory.

> We allready adapted a few bb files to get oe building our u-boot and kernel. Should we push out these changes?
> How?

Yes, please do.  There are two ways:

1) the old way: create patch files and post to the bugzilla
2) the better way: expose a git repo somewhere with your changes and
ask for review.  Once there are reviewed, someone with OE push access
can easily merge them for you

OE push access is typically granted after a person has made some
contributions and seems to have a handle on how OE works.

> We have two developers working at this project. Our board is AVR32 based. So, if oe is our major build system we would have to take care that avr32 allway builds. This means testing, fixing, extending support. I hope this would be benefit enough to endure our newbie questions while we are getting known with the build system.

Excellent, contributions are appreciated.

Thanks,
Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com

Re: Adding support for our

[mailinglist]

Hi, 

>> We have a new AVR32 based embedded linux board
> (www.miromico.com/hammerhead), which is available now. 
> That is a nice little board you have there. I personally like the AVR32
> architecture. Atmel also has the better policy when it comes to
> specifications. So I really like to see more AVR32 being used. :)

Thanks.
> 
>> We would like to use OpenEmbedded as our major build system to allow our
> customers to build their u-boot, 
>> kernel and rootfs.
> Great stuff. OE already supports the ATNGW100 (have one here) and the
> AT32STK1000. If your board can boot with the same linux 2.6.24 (or with
> patches to that) it will be quite easy to support your device.

Yes, I know. I have an ATNGW100 as well. The problem is, that the oe for
atngw100 
fails. It does compile (console-image), but I can't boot. I get a segfault
in init (sysvinit).

> 
>> Is there such a thing as a board maintainer in oe? If yes, how can we
> become one?
> We have a "MAINTAINERS" file. If you are a contributor you can add
> information about the machines you are maintaining. This mainly means
> that people will ask you when stuff breaks. In theory it should also
> mean that people will ask you *first* if things are changed in OE that
> affect your device but AFAIK we have no strict policies regarding this.

Ok, I'll check that out...

Alex

Re: Adding support for our

[Leon Woestenberg]

Hello Alex,

On Fri, Oct 17, 2008 at 7:42 AM, Alex Raimondi <mailinglist@miromico.ch> wrote:
>
> We have a new AVR32 based embedded linux board (www.miromico.com/hammerhead), which is available now.
> We would like to use OpenEmbedded as our major build system to allow our customers to build their u-boot,
> kernel and rootfs.
>
I am in the same ballpark; but for a custom board (not for sale).

> Is there such a thing as a board maintainer in oe? If yes, how can we become one?
>
Simply maintain the machine file and/or board-targetted images, the
kernel config (or patches) for your board, in some cases
board-specific packages.

Send patches using the bugtracker. If you provided quality patches,
you can request for commit access, but we ask you to be familiar with
OE first.

> We allready adapted a few bb files to get oe building our u-boot and kernel. Should we push out these changes?
> How?
>
bugtracker, sometimes being on #oe helps to speed up stuff. (have
people review/commit interactively).

> We have two developers working at this project. Our board is AVR32 based. So, if oe is our major build system we would have to take care that avr32 allway builds. This means testing, fixing, extending support. I hope this would be benefit enough to endure our newbie questions while we are getting known with the build system.
>
I regularly build for AVR32 (at32stk1000 and custom board) and
although it's the newest arch in OE AFAIK, I am quite happy with the
status of AVR32 support in OE. We are mostly waiting for upstream to
have AVR32 integrated (GCC, binutils, ulibc etc).


Another help might be to provide some OE developers with your board.
It helps having a more continuous developer base activity.
Please consider.


Regards,
-- 
Leon

Re: Adding support for our

[Robert Schuster]

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

Hi,

mailinglist@miromico.ch schrieb:
> Yes, I know. I have an ATNGW100 as well. The problem is, that the oe for
> atngw100 
> fails. It does compile (console-image), but I can't boot. I get a segfault
> in init (sysvinit).
> 
That is too bad and should be considered a bug. Since there are so few
AVR32-using people in OE toolchain changes (and I somehow believe this
is again a toolchain issue) which broke that arch went in undetected.

OTOH it would really help if Atmel would push their binutils et al
patches upstream ...

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]