All times are UTC-06:00




Post new topic  Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Tue Dec 28, 2010 9:46 am 
Offline

Joined: Thu Nov 25, 2010 6:29 am
Posts: 15
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.


Top
   
PostPosted: Fri Dec 31, 2010 7:25 am 
Offline

Joined: Thu Nov 25, 2010 6:29 am
Posts: 15
Quote:
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
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:
Code:
$ cp config-2.6.31.14.12-efikamx .config
$ ARCH=arm make oldconfig
scripts/kconfig/conf -o arch/arm/Kconfig
#
# configuration written to .config
#
This leads to a "default" .config for arm (which I'm not interested in):
Code:
$ diff -u config-2.6.31.14.12-efikamx .config | wc -l
138
Then, obviously, if I cross-compile with this overwritten (broken) config, bad things happen:
Code:
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make -j2 uImage modules
(long cross-compilation)
LD init/built-in.o
LD .tmp_vmlinux1
arm-linux-gnueabi-ld: no machine record defined
arm-linux-gnueabi-ld: no machine record defined
arm-linux-gnueabi-ld: no machine record defined
make: *** [.tmp_vmlinux1] Fel 1
Which googling around means:
Quote:
"(...)it points to inconsistencies in your .config against the defconfig."
How do you force/keep the "good" old configuration when re-cross-compiling your kernels without going on make menuconfig from scratch ?


Top
   
 Post subject:
PostPosted: Fri Dec 31, 2010 8:06 am 
Offline
Genesi

Joined: Mon Jan 30, 2006 2:28 am
Posts: 409
Location: Finland
Hi.

To cross compile:
Code:
export ARCH=arm
export CROSS_COMPILE=your-compiler-prefix-

make mx51_efikamx_defconfig

make
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


Top
   
PostPosted: Fri Dec 31, 2010 8:38 am 
Offline

Joined: Thu Nov 25, 2010 6:29 am
Posts: 15
Quote:
Hi.

To cross compile:
Code:
export ARCH=arm
export CROSS_COMPILE=your-compiler-prefix-

make mx51_efikamx_defconfig

make
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.
Thanks for the help Johan ! Unfortunately:
Code:
$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make mx51_efikamx_defconfig

***
*** Can't find default configuration "arch/arm/configs/mx51_efikamx_defconfig"!
***
Cannot find it anywhere in the official gitorious repo:

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

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


Last edited by brainstorm on Fri Dec 31, 2010 11:41 am, edited 1 time in total.

Top
   
PostPosted: Fri Dec 31, 2010 11:38 am 
Offline

Joined: Thu Nov 25, 2010 6:29 am
Posts: 15
Strange... I cannot track it back on git master after Nov 24...
Code:
~/dev/efika-kernel/arch/arm/configs$ git log --all -- mx51_efikamx_defconfig

$ git show 3f7b34dd5f3438fc1957c2d876e27c67cc52c8a6:arch/arm/configs/mx51_efikamx_defconfig > mx51_efikamx_defconfig
Let's see if that revision still works...

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


Top
   
 Post subject:
PostPosted: Fri Dec 31, 2010 5:35 pm 
Offline
Genesi

Joined: Mon Jan 30, 2006 2:28 am
Posts: 409
Location: Finland
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


Top
   
 Post subject:
PostPosted: Sat Jan 01, 2011 10:45 am 
Offline

Joined: Thu Nov 25, 2010 6:29 am
Posts: 15
Quote:
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
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 ! ;)


Top
   
 Post subject:
PostPosted: Tue Jan 04, 2011 7:39 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
Quote:
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
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).
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).
Quote:
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 ?
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.
Quote:
You'll perhaps consider on fixing them to ease access to newcomers.

Happy post-newyear btw ! ;)
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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 8 posts ] 

All times are UTC-06:00


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
PowerDeveloper.org: Copyright © 2004-2012, Genesi USA, Inc. The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
All other names and trademarks used are property of their respective owners. Privacy Policy
Powered by phpBB® Forum Software © phpBB Group