New kernel ?

Hi

How does one go about porting a newly released Linux kernel such as 2.6.36
to the Mini2440?

Thanks

The main issue is that you have to ensure all the patches that have been
applied to either the kernel at http://repo.or.cz/w/linux-2.6/mini2440.git
or the kernel on the download page are then applied to 2.6.36 OR some
hardware bits will just NOT work.

I have not heard that 2.6.36 is up to-date with these changes.

There are have been several postings recently dealing with this topic.

Ok

So who updates it ?

It appears as if the kernel you mention in the link is maintained by
someone so thats more like copying existing stuff.

What makes the kernel for the mini2440 different from the traditional
kernel we would use on PCs ?

Is it not possible to have a predefined set of patches to apply to each new
kernel as it is released to create what we would know as a patched kernel
for the mini 2440 ?

I am trying to determine whether or not this is something which can be done
by yourself or if it is dependent on other people whom one has no control
over.

It has been a long confusing story.

buserror (link mentioned) did the most useful work, but it appears those
changes could or did not make their way into the main kernel tree.  I don't
know what the current situation is.

There has been no official maintainer.

Several bits of hardware would not work using kernels that do not have his
mods.  As I recall __init_data (?) in the machine specific file seems to be
the biggest issue.

Patches . . . it sounds sensible, but I am no patch expert.

Your last comment generated quite of discussion as well.  Search for <bob>
and his views on every Tom, Dick and Harry patching kernels and floating
them on the internet.

Hopefully, the situation will improve with the mini6410.

I'll try to check latest vanilla kernel and post patches with missing stuff
to mainline. Will see ;)

I was trying to determine if there exists a generic approach to creating a
new source tree from the newly released kernels or if it has to work the
other way around wherein one has to work the kernel patches into the
existing kernel for the 2440.

If there are many people who will benefit from a well maintained kernel,
why isn't someone doing it.

I'm getting the impression that it may be abandoned ?

OK

Downloading vanilla 2.6.32.2 to see how different this one is that we have
currently for the mini 2440

Maybe we can devise a simple method of patching any new kernel.... I doubt
it, but its still a maybe :)

I picked up a board on ebay so at least I'll have something to test on
within the next couple of weeks

I did a check on ebay and couldn't find a 256MB RAM unit.  Could you give
me the link?

Thanks,
Dave

Hi davef, AndreT. If anybody interested to push mini2440 changes to
mainline, could we somehow coordinate to avoid duplicate work? I can make
diff what isn't in mainline and post a list what should be merged to
mainstream. Or anybody already to this?

open-nandra,

First off, I don't have the skills to do this.  I had a go at trying to
encourage someone to coordinate this, but no one seemed keen to take this
on.

Here is the thread I was talking about:
http://www.friendlyarm.net/forum/topic/1094

As far as I am aware no one has done this since buserror late last year. 
And my impression is that buserror's patches never made into the mainline
kernel.  
http://repo.or.cz/w/linux-2.6/mini2440.git


Russell King and Ben Dooks are the names of two guys that seem to have a
lot to do with the main arm input into the kernel and Samsumg specific
stuff. 

http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
http://blog.gmane.org/gmane.linux.kernel.samsung-soc


I would be real useful if you could do a diff on buserror's latest kernel,
the one posted in the downloads section and the latest stable kernel
(2.6.36).

Then maybe if it was published and see what discussion it generates.

I am not a "power-user", but would appreciate things being keep up to date.
 I would like to continue using the mini2440s, as I have two of them and
might buy a mini6410.

Good luck,

Regards,
Dave

Anyway in attachment is patches differs from 2.6.32-rc8 kernel and in next
post also whole diff.

Whole diff.

@davef

I got one with 64MB ram and 1GB Flash - Dont think I've seen ones which
have 256MB ram?

@open-dandra & davef

I was thinking of doing it a little differently... the patch thing.

I want to write a small utility which checks for differences between our
current base (the vanilla 2.6.32.2) and the new base (the vanilla 2.6.36 or
what ever other new kernel comes out)

Once I have it comparing the two vanilla kernel's I want to add
functionality to run through the source tree of the current mini 2440
kernel allowing us to select source changes applicable to the vanilla
kernel's and apply them to the mini2440 kernel thereby upgrading the kernel
to the new version.

Do you think this might be a sensible approach?

AndreT seems to me reasonable. But differences could be such a big that we
overlook something. Anyway wait for your results ;).

Maybe you're right... maybe we should try just leap to the next stable
which I think is 2.6.33.7

Well we have a patchset from 2.6.32 and we could apply to latest vanilla
and fix possible problems and post patches mainstream. Then we will have
everything in mainline and we don't need to maintain our tree and also we
can use new functions. Step to 2.6.33 is possible but latest stable is
2.6.36 so we are still behind.

So the idea is to get it up to date with what ever the latest kernel is
(currently 2.6.36) so that we can get it included into mainline ?

Yes this is idea. Then user ask for kernel and reply will be download
vanilla and use it ;)

Can't believe this . . . in less than an hour or so you two seem to be
managing your way to a solution.

Hope the rest of the process works as smoothly.

Dave

First problem.... there are some patches missing.

What I did is took a vanilla 2.6.32.2, which is what I believed the current
kernel we're using for the mini2440 is based on.

I then applied the patches attached in an earlier post here by open-nandra
and created a diff from that to the kernel source we're using at the
moment.

Attached is the difference (missing stuff)

Obviously some of it is easily explained as config files etc but there are
some other issues which will need to be addressed.

open-nandra, any reason why you used 2.6.32-rc8 ?

Well master branch from  git://repo.or.cz/linux-2.6/mini2440.git is
2.6.32-rc8 so I used this like reference. Do you use different branch?

Now I'm really confused.

If I look at arch\arm\mach-s3c2410\include\mach\leds-gpio.h on the patched
version of my vanilla 2.6.32.2 i find:

#define S3C24XX_LEDF_STARTON  (1<<2)    /* Initialise 'on' */

If I look in the same file of the source tree we're currently using for the
mini2440 its not there!

There's a lot of work here.... hehehe

Well we can extract patches what we have from old kernel try to apply to
latest mainline kernel tree and fix a problems. Or exist better way. This
will be long way :D.

I get differences the other way around also, for example:

\arch\arm\plat-s3c24xx\Kconfig on the kernel tree we're using for the m2440
contains:

config MACH_FRIENDLY_ARM
  bool
  help
    Common machine code for FriendlyARM boards i.e. Mini2440, etc


BUT this does not exist in my patched version of the kernel.

We can take mainline kernel like reference and merge our local changes
here. Or?

There are things which exist in the patches which do not exist in the
current version of the mini2440 kernel source.

There are things which exist in the current mini2440 kernel source that do
not exist in the patches.

I think if we can first fix the discrepancies between the patches and the
vanilla 2.6.32.2 kernel so that we actually have a working set of patches
for the 2.6.32.2 kernel that would be a good first step.

We can then run through the patches from 0001 through 0011 and fix them
until they can be applied to the 2.6.36 kernel.

I think this will be the simplest?

Well OK, we can go this direction. Will you do this or we can somehow split
work?

Its always nice to split work.

How do you want to do this?

Which time zone are you in? I'm GMT+2

I'm GMT+1. We can split patches which will be checked. Which series you
take? patch 1-5 or 6-11 ;)

I'll do 1-5 :)

Attached is a list of files which do not matched.

Left side is what we currently know as the mini2440 kernel source.

Right side is the result of taking a vanilla 2.6.32.2 and patching it with
the patches you uploaded earlier.

Some files only exist in mini2440 kernel and others only exist in vanilla
2.6.32.2 kernel. 

I am not sure how will will handle these differences now but we need to do
this and work them into the patches before we can start fixing patches to
work with 2.6.36.

Unless you have another idea?

Lets do it primitive. Merge or apply a patch to 2.6.32.2. Fix problems test
on board. Maybe we can setup some repo.or for such a work to be
synchronous.

FYI I apply all patches from mini2440 2.6.32-rc8 kernel to 2.6.32.2 kernel
without any problems.

Tried to copy the .config into your newly patched kernel and compile?

Well no just apply patches. Now trying apply those patches for latest
mainline. There are some conflicts but seems solvable. Could you please
test 2.6.32.2 with applied patches? Thx.

It does not compile :)

This is what I was saying in previous posts that there are issues which
need to be "patched" that are not covered by the patches you have.

OK lemme look.

The patches do not turn a vanilla 2.6.32.2 into a usable source tree.

I think we need to solve this before trying to apply them to 2.6.36 ?

Can't we discuss other way? gmail, skype? mine: marek.belisko at gmail.com,
skype: marekwhite.

The more i look at it, the more I am convinced that the mini2440 patches
are in mainline.

make menuconfig ARCH=arm

set all the options, including some new ones and dont forget to set
cross_compiler = 'arm-linux-' under general

make zImage ARCH=arm

I do not have a board yet (will have it in 2wks or so) so I cannot test.

>  I don't know what the current situation is.

Well, if they have finally got into the mainline that is good news. As I
recall 2.6.32 stable didn't have them.

Has anyone been able to compile 2.6.36 and get everything to work on the
mini2440?

AndreT,

When you say "it does not compile", what is (are) the error message(s) that
you get?

It does compile

I tried to patch 2.6.36 which was already patched as it appears the support
for the mini244 is already included in mainline

did you try to compile the kernel as per my previous post?

Mine compiles, but i dont have a board to run it on (yet)

I meant to say, my previous post implies that you can download vanilla
2.6.36 and perform the steps:

make menuconfig ARCH=arm

set all the options, including some new ones and dont forget to set
cross_compiler = 'arm-linux-' under general

make zImage ARCH=arm

Been away for two days.  I understand that you have now been able to get it
to compile. I have the kernel, but will have to try compiling it tomorrow
night.  It's almost midnight in New Zealand.

Hi guys. 2.6.36 compile for mini2440 but not all work from buserror is in
mainline. Lemme check tomorrow which patches are missing and sent them.

Well new kernel start but then go to panic. Have to investigate.

Could be that its trying to load a driver which doesn't belong to the mini
2440.

I'm swamped with work today :(

Well no I already fix that and have 2.6.37-rc1 running on my mini2440
board. There is some issue with touchscreen but have to firt post fix
patches mainline.

Well done!

Emailed buserror, basically asking how he would suggest support of the
mini2440 flavour of the kernel could proceed.

Why can't FriendlyArm publish the patches that they use to tweak the
kernel?

The ARM kernel guru at work said that it would be "an epic job updating
2.6.32 to 2.6.36".  I guess someone needs to keep on top of the changes
required release by release or things get out of control pretty fast.

Good luck.
Dave

Well not sure about what's the process what FriendlyARM has for kernel but
lot of functionality is already in 2.6.36 kernel. I post 3 patches already
and board nicely bootup and is usable. So wait till patches will be
accepted and then use just vanilla kernel. Not sure if we need ported ts
from openmoko because there is already a ts driver (used also for 64xx).S o
patches which you could apply to your 2.6.37-rc1 trees: 
http://lkml.org/lkml/2010/11/8/106
http://lkml.org/lkml/2010/11/8/114
http://lkml.org/lkml/2010/11/8/121

open-nandra,

Just to check my understanding:

- lkml is another route to get patches into the kernel?
- do Ben Dooks or Russell King have to process these patches?
- could the patches be applied to 2.6.36?

I imagine you are notified when these changes are actually placed in the
mainstream.  Then would you advise the forum of this fact?

I appreciate the effort you (both) have put into sorting out the confusion.


Regards,
Dave

I see two of the patches are also listed on:

http://lists.infradead.org/pipermail/linux-arm-kernel/2010-November/thre...

So, my first and second questions are probably irrelevant.

dave

open-nandra.

One last (?) request.

Would you mind attaching your .config file or did you use the
mini2440_defconfig that came with 2.6.37-rc1?

Thanks,
Dave

Here you are.

I see kernel has gone rc2.

Got my board... need to get rid of the chinese rootfs and start toying with
the kernel.

Dear all,

I tried the latest 2.6.37 vanilla kernel with a make mini2440_defconfig but
the sound is broken. Who has also tested this vanilla version?

Working version (I think it is from buserrors git):
Linux version 2.6.31 (jerry@hell) (gcc version 4.3.2 (Sourcery G++ Lite
2008q3-72) ) #1 Tue Feb 15 20:13:43 CET 2011

Output on boot:
Advanced Linux Sound Architecture Driver Version 1.0.20.
No device for DAI UDA134X
No device for DAI s3c24xx-i2s
S3C24XX_UDA134X SoC Audio driver
UDA134X SoC Audio Codec
asoc: UDA134X <-> s3c24xx-i2s mapping ok
ALSA device list:
  #0: S3C24XX_UDA134X (UDA134X)

With the latest vanilla at boot output:

S3C24XX_UDA134X SoC Audio driver
ALSA device list:
  No soundcards found.

It also doesn't show up in /class/dev/sound

Kind regards,
Jerry

Has open-nandra's patches made it into this kernel?  Or are you applying
the patches as above.

Sorry guys I don't check audio. My patches are stuck don't know where. I
can check also also and post some patch ;).

marek

Another issue is:

- I am pretty darn sure that you have do a config_min2440_xxx, xxx being
the touchscreen you are using, for a complete configuration of the mini2440
to take place. 

Maybe, this will help:
http://code.google.com/p/friendlyarm/wiki/Linux_Tutorial