Lite5200 MTD partitions in 2.6 build

Lite5200 MTD partitions in 2.6 build

[Rowan, Chad]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

In the 2.4 build I had to modify icecube.c in /linux/drivers/mtd/maps/ to
specify the u-boot, kernel image, and root fs partitions.  Icecube.c doesn't
exist in the 2.6 drop.  I got the top of the tree from the denx git
yesterday.  How do you config the partitions for the 2.6 kernel?

 

Thanks,
Chad


[-- Attachment #2: Type: text/html, Size: 1679 bytes --]

Re: Lite5200 MTD partitions in 2.6 build

[White]

Am Tue, 27 Jun 2006 13:38:25 -0500 schrieb "Rowan, Chad"
<Chad.Rowan@thyssenkrupp.com> :

> In the 2.4 build I had to modify icecube.c in /linux/drivers/mtd/maps/ to
> specify the u-boot, kernel image, and root fs partitions.  Icecube.c doesn't
> exist in the 2.6 drop.  I got the top of the tree from the denx git
> yesterday.  How do you config the partitions for the 2.6 kernel?
> 
>  
> 
> Thanks,
> Chad
> 

Please throw a look to the Platform Devices MTD memory Mapper.
(drivers/mtd/maps/plat-ram.c)

With this Info you can add the Info to the Plattform Device List. f.e.
in the Board Support File. (lite5200.c ?)


Good Luck,
Gabor

how to get individual patches

[David H. Lynch Jr.]

    The bsp I am working on works with 2.6.16.21 but fails with 2.6.17.
   
    How can I find the individual patches that make up the transition
from 2.6.16.21 to 2.6.17 ?

    I guess I can use interdiff to create single patch to go from
2.6.16.21 to 2.6.17 but I am really looking to get all the individual
patches so I can try to isolate exactly
    what is giving me trouble.

-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: how to get individual patches

[Alex Zeffertt]

David H. Lynch Jr. wrote:
>     The bsp I am working on works with 2.6.16.21 but fails with 2.6.17.
>    
>     How can I find the individual patches that make up the transition
> from 2.6.16.21 to 2.6.17 ?
> 
>     I guess I can use interdiff to create single patch to go from
> 2.6.16.21 to 2.6.17 but I am really looking to get all the individual
> patches so I can try to isolate exactly
>     what is giving me trouble.
> 

For diffs of individual files between official kernel releases you can
use

	http://www.linuxhq.com/kernel/

It's really good!

Alex

Re: how to get individual patches

[David H. Lynch Jr.]

Alex Zeffertt wrote:
>
> For diffs of individual files between official kernel releases you can
> use
>
>     http://www.linuxhq.com/kernel/
>
> It's really good!
    They appear to be updating or something at the moment. I can not get
to most pages.


>
> Alex
>


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: how to get individual patches

[Grant Likely]

On 6/28/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>     The bsp I am working on works with 2.6.16.21 but fails with 2.6.17.
>
>     How can I find the individual patches that make up the transition
> from 2.6.16.21 to 2.6.17 ?

Unfortunately, there isn't a direct line between .16.21 and .17 which
makes it complicated.  Does your bsp work with .16?  If so; you can
use the 'git bisect' command to figure out exactly where the
regression occured.

If it doesn't work on .16; you can do a bisect between .16 and .16.21
to figure out what patch is missing between .16 and .17.

$ git bisect good v2.6.16
$ git bisect bad           # the head of the tree
compile, test, etc.
$ git bisect good|bad    # depends on whether it works or not
compile, test, etc
$ git bisect good|bad    # you get the idea... repeat until it's narrowed down
$ git log                          # see where you are in the git tree.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: how to get individual patches

[David H. Lynch Jr.]

Grant Likely wrote:
> On 6/28/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>>
>>     The bsp I am working on works with 2.6.16.21 but fails with 2.6.17.
>>
>>     How can I find the individual patches that make up the transition
>> from 2.6.16.21 to 2.6.17 ?
>
> Unfortunately, there isn't a direct line between .16.21 and .17 which
> makes it complicated.  Does your bsp work with .16?  If so; you can
> use the 'git bisect' command to figure out exactly where the
> regression occured.
>
> If it doesn't work on .16; you can do a bisect between .16 and .16.21
> to figure out what patch is missing between .16 and .17.
>
> $ git bisect good v2.6.16
> $ git bisect bad           # the head of the tree
> compile, test, etc.
> $ git bisect good|bad    # depends on whether it works or not
> compile, test, etc
> $ git bisect good|bad    # you get the idea... repeat until it's
> narrowed down
> $ git log                          # see where you are in the git tree.
    Thanks,

       At the moment I am not working out of a git tree - but I was
previously.
   
       What I have works with everything from 2.6.15 through 2.6.16.21 -
or atleast the 15+ odd interim steps I tried.
    It fails if I go from 2.6.16 to 2.6.17.

       I can probably actually check into why it is not working - looks
alot like an ml403 mmu hang posted earlier (I am working with a Xilinx V4).
    But I was hoping I could get away with brute force/divide and
conquer and isolate it to a single patch before actually trying to
figure out the problem.

    I am going to have to get better at git.
>
> Cheers,
> g.
>


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: how to get individual patches

[David H. Lynch Jr.]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

Grant Likely wrote:
> On 6/28/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>   
>>     The bsp I am working on works with 2.6.16.21 but fails with 2.6.17.
>>
>>     How can I find the individual patches that make up the transition
>> from 2.6.16.21 to 2.6.17 ?
>>     
>
> Unfortunately, there isn't a direct line between .16.21 and .17 which
> makes it complicated.  Does your bsp work with .16?  If so; you can
> use the 'git bisect' command to figure out exactly where the
> regression occured.
>
> If it doesn't work on .16; you can do a bisect between .16 and .16.21
> to figure out what patch is missing between .16 and .17.
>
> $ git bisect good v2.6.16
> $ git bisect bad           # the head of the tree
> compile, test, etc.
> $ git bisect good|bad    # depends on whether it works or not
> compile, test, etc
> $ git bisect good|bad    # you get the idea... repeat until it's narrowed down
> $ git log                          # see where you are in the git tree.
>
>   
    Thank You git bisect has proven to be incredibly interesting.

    One question/problem - maybe an incomplete understanding of git.
   
    What I need to do is get to some version of 2.6.16 - as they all
work for me.

    cut in my patches.

    And THEN start bisecting while retaining my patches.

    Is that going to work or am I going to have to repatch each time ?

    Basically can I use git to insert a patch into the middle of its
delta history and then advance forward from there ?

    It is rapidly becoming obvious that competence with git could have
big payback.

   

   











-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein


[-- Attachment #2: Type: text/html, Size: 2991 bytes --]

Re: how to get individual patches

[Grant Likely]

On 7/14/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>      Thank You git bisect has proven to be incredibly interesting.
>
>      One question/problem - maybe an incomplete understanding of git.
>
>      What I need to do is get to some version of 2.6.16 - as they all work
> for me.
>
>      cut in my patches.
>
>      And THEN start bisecting while retaining my patches.
>
>      Is that going to work or am I going to have to repatch each time ?

AFAIK, yes you will have to repatch every time; I typically write a
little helper script to lessen the pain:

git bisect good|bad # depends on whether it works or not
patch < [patchfile]
compile, test, etc
cg restore -f     # Remove the patches
git bisect good|bad   # lather, rinse, repeate

>
>      Basically can I use git to insert a patch into the middle of its delta
> history and then advance forward from there ?

I don't think so; no automatically; but if you don't commit your
changes then it's easy to drop the change the patch makes.

git-rebase does something similar to what you're trying to do; but
it's complex to use (especially if there are conflicts) and might
conflict w/ the git-bisect tool

>
>      It is rapidly becoming obvious that competence with git could have big
> payback.

:)

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: how to get individual patches

[David H. Lynch Jr.]

Grant Likely wrote:
> On 7/14/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
> AFAIK, yes you will have to repatch every time; I typically write a
> little helper script to lessen the pain:
>
> git bisect good|bad # depends on whether it works or not
> patch < [patchfile]
> compile, test, etc
> cg restore -f     # Remove the patches
> git bisect good|bad   # lather, rinse, repeate
>
    Alright, I have bisected my way down to the problem.
    Well sort of.
    I think the real problem I started looking for eventually got fixed
in the kernel tree on its own.

    But I did find a real problem. I have found my own work around - but
this problem may effect others.

    The zlib library was updated within the past month.
    The new zlib code does not work in my environment.
    I have guesses as to why, but I am not a zlib expert and not looking
to be one.
    I have solved my personal problem by reverting to the older zlib code.
    With that I have 2.6.18-rc4 or whatever is in the linux-2.6 git tree
as of today working for me.
    I was stuck at 2.6.16.21 before.
   
    So my questions:

    How/where do I report a problem ? I would be perfectly happy to help
whoever is responsible for zlib to work this out.
    But I am not up to doing it myself.

    git bisect got me down to a good/bad scenario. But I could not
provoke git to either pull the offending patch or export the change as a
patch so that I could back it out myself.
    Now that the final git bisect screen is gone all I have (besides a
fixed 2.6.18-xx kernel) is I guess the sha has number for the particular
commit.
    I suspect that would have been enough to yank just that patch but I
googled every permutation of git backout or similar things I could think
of and browsed the git tutorials etc.
    and could not seem to decipher how to do anything usefull with the
sha id of a single patch.
    I am sure that is a knowledge problem.






-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: how to get individual patches

[Grant Likely]

On 7/16/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>     The zlib library was updated within the past month.
>     The new zlib code does not work in my environment.
>     I have guesses as to why, but I am not a zlib expert and not looking
> to be one.
>     I have solved my personal problem by reverting to the older zlib code.
>     With that I have 2.6.18-rc4 or whatever is in the linux-2.6 git tree
> as of today working for me.
>     I was stuck at 2.6.16.21 before.
>
>     So my questions:
>
>     How/where do I report a problem ? I would be perfectly happy to help
> whoever is responsible for zlib to work this out.
>     But I am not up to doing it myself.

Once you've got the patch extracted (see below); post it to the lkml
with a description of your symptoms and what you are trying to do.
(or post it here, and if nobody knows; then move over to the lkml)

>
>     git bisect got me down to a good/bad scenario. But I could not
> provoke git to either pull the offending patch or export the change as a
> patch so that I could back it out myself.
>     Now that the final git bisect screen is gone all I have (besides a
> fixed 2.6.18-xx kernel) is I guess the sha has number for the particular
> commit.

git-format-patch <good_sha1>..<bad_sha1>

for example:
$ git-format-patch
0ce030395b92270567423d57d9d432eb77df32f2..8d92bc2270d67a43b1d7e94a8cb6f81f1435fe9a
0001-PCI-Error-handling-on-PCI-device-resume.txt

extracts a single patch file for the
PCI-Error-handling-on-PCI-device-resume.txt commit.  If there are more
than one commits between <good_sha1> and <bad_sha1>, then you'll get
more than one patch file extracted.

Then, you can apply the patch reversed to backout the change.

>     I suspect that would have been enough to yank just that patch but I
> googled every permutation of git backout or similar things I could think
> of and browsed the git tutorials etc.
>     and could not seem to decipher how to do anything usefull with the
> sha id of a single patch.

"git-log <sha1>" will give you the history starting at a particular
commit, which is useful for finding the next commit after it for doing
the git-format-patch command.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195