Hello...

I was wondering how you people manage the .config changes on the efika kernels... I had to mount the latest Maverick SD-card and:

<code>
cp config-2.6.31.14.12-efikamx .config
make oldconfig
</code>

And answer to a bunch of questions (as part of the kernel config).

I think it would be much more agile to have the latest ".config" directly on the Gitorious repository, isn't it ?... or have a limited set of .config for smarttop and MX, for instance.

Apparently oldconfig overwrites .config... how do you cross-recompile the kernel just after cloning it out from gitorious ? I did:
This leads to a "default" .config for arm (which I'm not interested in):
Then, obviously, if I cross-compile with this overwritten (broken) config, bad things happen:
Which googling around means:
How do you force/keep the "good" old configuration when re-cross-compiling your kernels without going on make menuconfig from scratch ?

Hi.

To cross compile:
The mx51_efikamx_defconfig is in the Git repo. So is mx51_efikasb_defconfig for the netbbook. They are the default configs, and are under arch/arm/configs/.


Johan.

_________________
Johan Dams, Genesi USA Inc.
Director, Software Engineering

Yep, I have a blog... PurpleAlienPlanet

Thanks for the help Johan ! Unfortunately:
Cannot find it anywhere in the official gitorious repo:

http://gitorious.com/efikamx/linux-kern ... rm/configs

The closest one being:
But I guess it's not close enough to the custom default "efika" config.

Strange... I cannot track it back on git master after Nov 24...
Let's see if that revision still works...

Edit: Nope, it doesn't :-/ Can someone explain me why and/or fix it upstream ? Thanks !

Hi Bainstorm,

Make sure you're in the efikasb-10.08.00 branch!

It's right here:

http://gitorious.com/efikamx/linux-kern ... rm/configs


Oh, and, Happy New Year!

Best regards,
Johan

_________________
Johan Dams, Genesi USA Inc.
Director, Software Engineering

Yep, I have a blog... PurpleAlienPlanet

Yeah, finally that did the trick... Thanks !

IMHO, there are some quite counter-intuitive issues in this repository:

1) It is considered bad practice to have a non-working "master" branch. *Working* (production) improvements should be merged back to master whereas other branches such as efikasb-10.08.00 be considered as experimental (under active development).

2) Having myself an Efika MX, is "efikasb" the branch I should use ? Or should I go for "efikamx-10.07.11" ? Is it feasible to have a single merged "generic" branch such as "efika-10.08.00" to be used by both devices ?

You'll perhaps consider on fixing them to ease access to newcomers.

Happy post-newyear btw ! ;)

It's bad practice for Linux development but not for real work. I want to keep commits out of master and pull them back in. Branches are for feature work. Right now "one that supports the Efika" is a feature in itself.

Since we have to support a hardware platform here and not just send in some innocuous tweaks to some subsystem maintained in another tree, it makes no sense to me to have a branch for every driver subsystem that we modify independently. When the system is so tightly integrated in an SoC as compared to, say, an Intel box.. it is difficult to change one thing and not have it adversely affect a bunch of other stuff too.

We're moving away from Gitorious and the concept is basically to keep the BSP code in branches, merge to master, develop major releases in branches, merge to master. This will be on Github, but we need Freescale to sync upstream to the BSP we need first (and it'll be 2.6.35, and once the port is done, we're bouncing to mainline).
Use the efikasb-10.08.00-20101205 tag from the efikasb-10.08.00 branch. It's misnamed. Yes, it would be nice to have a generic branch name for it, but in the end it is just a marker.. the name doesn't mean anything, you should work from HEAD~n or from tags or commit hashes.
It's very hard to fix it once it's committed and has been cloned by someone, and especially on gitorious (which may be good for a lot of people but has been notoriously unreliable for most).

Moving to a clean tree elsewhere is the best route, which we are doing, but we want to get the code at the point we have it to a decent level first (new battery driver, fix HDMI, etc.) before this gets dropped in a new branch on a new kernel. It doesn't make any sense to me to import a bug.

_________________
Matt Sealey