On Mon, Jun 13, 2011 at 9:30 AM, Nick Bane <
nickbane1@gmail.com> wrote:
>
>> I am curious to learn what the typical workflow is for folks who hack
>> the kernel on the Balloon board. What I have been doing seems prone
>> to error and lossage and I'm sure there must be something easier.
>>
> That is probably mostly me - I am on 2.6.39.1 now and testing 3.0-rc1. Feel
> free to ask.
Thanks. Would you recommend that I play with the 3.0 kernel, or stay
with the 2.6.37.6 kernel that I got out of the default configuration?
I don't have any personal attachment to either kernel.
>> Anyway, I've checked out svn trunk and run through the build process
>> to generate a kernel.
>>
>> Now I want to change something, say perhaps, the NOR flash
>> partitioning that's defined in balloon.c. Thus far, I've simply been
>> hacking away at
>> build/kernel//linux-2.6.37.6/arch/arm/mach-pxa/balloon3.c.
>
> Be aware that changing what /dev/mtdblock<n> refers to can cause confusion -
> the initramfs system assumes mtdblock0 for nand boot partition. If you can
> find a way to have the NOR partitions appended to the NAND partitions then
> that would be very helpful.
yep -- actually it seems to be more a function of parameters stored in
bootldr than parameters stored in the initramfs.
I've been trying to figure out the partition order thing for the last
day or so. I'm almost at the point of saying, "Well, since I'm the
only one who wants to program the NOR flash from a running kernel, I
can change the bootldr parameters to deal with the change in mtdblock
partitions." I would really like to do things the right way, but at
some point the "too hard" light is going to come on and I'll just
punt.
But I _really_ want to do it the right way!
Sigh.
>>
>> I already know I'm in trouble because I forgot to do a "quilt new" and
>> to "quilt add" balloon.c before I started modifying it.
>>
>> What do folks do when they realize they've modified a file that is not
>> under quilt control? Or is this just a newbie mistake that none of
>> you make anymore?
>>
> Its a really common quilt "gotcha". I move the modified file/replace
> it/quilt new/quilt add/move back/quilt refresh and try not to do it yet
Is there a "quilt put this file back the way you think it should be" command?
That would be handy, especially here where balloon.c is part of a
whole series of patches.
> again. Note that when a file like balloon.c exists in multiple series files,
> applying patches needs to be done with due regard for the sequence of
> patches or it gets very tangled eg if you make balloon3nor.patch which you
> use on top of 3 other patches that use balloon.c , another series (say on
> which misses out the vga patch) may find it doesn't apply cleanly. For NOR
> it might be best to modify the base patch for balloon3.c and have the
> facility selectable via kernel config setting.
If I get things working, I'll a add kernel config setting for it. I
really want to do this the right way.
>>
>> Of course, since it's in the build directory, even once I get the file
>> properly under quilt control, I still need to remember to copy the
>> patch& series files out of the build directory and into the
>> packages/kernel directory tree, right?
>
> Quilt refresh should leave the updated patches in the package dir and not in
> the build dir.
ok... I missed the fact that the build/.../patches directory was
symbolically linked back to the packages directory, That makes sense.
This is where you can feel free to say, "try it once next time, then
come back and ask, oh yeah, and stop pestering us with hypothetical
questions when you haven't even tried it yet."
>
>> Or is there some easier way to do this?
>>
>> I feel like I know what all needs to be done, but what needs to be
>> done seems ridiculously, tediously, error proneously difficult. Am I
>> just a whiner, or do you all have tips and tricks that make this
>> easier? Or am I just going about this the wrong way to begin with?
>>
> It looks a bit obscure at first but really just boils down to quilt and
> series files. Chris Jones recently went up this learning curve and, although
> it looked mysterious, I think he has come to be content with it. He was also
> documenting his progress so that folks like yourself would have an easier
> time.
It's looking less obscure now, but I still worry about dropping
something on the floor. Perhaps I'm spending more time worrying than
any time I would lose from actually having dropped something.
>
> I maintain my own sandpit (branches/menuconfig2) that I find fairly stable
> for what I want to do (development work) while Hector merges useful patches
> to trunk. Feel encouraged to make constructive criticism as it is too easy
> us to forget how hard it all seems.
>
> Nick
Thanks again.
--wpd
(text/plain)