Port of latest Linux to 5485. Anyone done it?

[svision]

 Hi,

  It appears that you cannot find a port on freescales website that ports the latest version of Linux to the 5485 coldfire. We "think" we need the latest port because of some of the recent changes, but again I cannot find anything.

  We are looking into doing this but don't want to re-invent the wheel if someone has done a port to the 5485 development board.

  So is there anyone out there that would like to share?

SVision

[comio]

Dear All,

   
I just saw this post. I am also interested in an upgrade the kernel.

My activities are now blocked by the kernel because I have a lot of 3rd party software that need a recent kernel. For this reason I'm interested to use also an unstable/beta kernel (for now).

Here I made the same questions:
 http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=3738

luigi


Message Edited by comio on 2008-01-04 06:53 PM

[aeg]

*PING*

Any news or updates ?

Best,
Andreas

[comio]

I can share my 2.6.23 port. Send me a message with your job mail.

ciao

[kmahan]

I'm wrapping up the 2.6.23 port to M5445x for the upcoming BSP.  A number of issues relating to paging and caching have been fixed.  I ended up rewriting most of the caching as it was causing a lot of problems.

[svision]

Kmahan,

  when will this be available to the public and where can I get it?

Dorion

[kwong]

svision: At this point, the port I have is pretty useless until I can get it stabilized.

kmahan: If you've got time to take to read up on the following symptoms, I'd like you to comment on whether or not the problem I'm encountering is something that I may also see in the 2.6.23 if I try porting that to the 547x.

As my port currently sits, The kernel startup fails before reaching the point of mounting the root filesystem.  After quite a bit of debugging, I've discovered that the problem lies in the "resume function" within entry.S file.  It always fails on the same instruction consistently.

The instruction that fails is attempting to reference memory that doesn't have an appropriate TLB entry.  Upon further digging, I found out that the necessary TLB entry was the most recently swapped out one.

The down and dirty specifics at the point of failure:

• The instruction is moveal %a1@(436), %sp
  
• It's in the second half of the "resume function"
• • From my limited understanding, it's pushing information about the new task onto the stack
• The specific virtual address being requested in the first operand is 0xc3831f48
• The DTLB page that covered that address was swapped out during the last TLB miss
• The processor seems to halt after attempting to execute the aforementioned instruction
  

I guess the question is, why doesn't the request for 0xc3831f48 result in another TLB miss?

Thanks,

Ken.

[kwong]

I don't suppose I could get a sneak peek at the changes you've made?

[kwong]

I'm working on cleaning up the m5445x port of the Linux 2.6.20 kernel over to the m547x architecture.

I've got it booting to a shell but it's extremely unstable at this point.  I have suspicions that the page table entries aren't being setup properly but I haven't confirmed that as of yet.

I'm not sure what the company stance is on sharing the preliminary work is but I can find out if you're interested.

Ken.

[svision]

Yes, if you can check that would be great.

Anything at this point would definately help.

Dorion