[oe] E-Ten Glofiish M800 support

Stefan Schmidt stefan at datenfreihafen.org
Tue Nov 18 18:44:33 UTC 2008


Hello.

On Tue, 2008-11-18 at 17:57, Koen Kooi wrote:
> On 18-11-08 16:59, Stefan Schmidt wrote:
>>
>> I just pushed a branch with basic machine and kernel support for the M800 from
>> E-Ten. Normally Winodws Mobile based device. Linux support is ongoing.
>>
>> http://git.openembedded.net/?p=openembedded.git;a=commitdiff;h=0ea0875a3e5456f701df08e0974821a4e8852f55
>>
>> As it is just machine, kernel recipe and sane-srcrev it should not break
>> anything. Still I would like to ask for review before pushing it in.
>>
>> How does folks feel about it?
>
> Only some small comments:
>
> conf/machine/eten-m800.conf:
> IMAGE_FSTYPES ?= "tar.gz"
>
> change that to += so people don't shoot themselves in the foot too easily

Good point. Changed.

> linux-eten_2.6.24+git.bb:
> git://git.openmoko.org/git/kernel.git;protocol=git;branch=stable \
>
> Would it make sense to merge this into the openmoko kernel recipe since  
> it's building from the same tree? I'm trying to cut down the number of  
> linux-foo recipes whenever possible, but it a seperate recipe is easier,  
> go for it.

I thought about this. My point about not doing it is that it could easily be
that I switch the git repo soon. We just sat up a git tree with WIP stuff. Not
sure which one I like to have in OE in the long run. I would go for keeping it
and think about how it turns out.

> do_configure_prepend() {
>   install -m 0644 ${S}/arch/arm/configs/glofiish_defconfig  
> ${WORKDIR}/defconfig
>
> Please include the defconfig in OE, it's really tedious to have to add  
> patches to SRC_URI when changing the defconfig.

Damn, got me. ;)

This is the usual kernel hacker vs. buildsystem maintainer problem. With my
kernel hat on I would like OE to use the newest defconfig to keep in sync
easily. With the OE hat I see that it sometimes makes sense to have a seperate
defconfig. Will put a defconfig in.

> Everything else looks good.

Great, thanks for the review.

If nobody else finds problems with this I'll push it in tomorrow.

regards
Stefan Schmidt

PS: Any people prefer to have patches inlined for easier review, or are all fine
with a link to webgit here?




More information about the Openembedded-devel mailing list