> 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.
>
There is a fair body of stuff that breaks with 3.0 - yaffs, buildroot,
debian .. erm. Scripts testing for not 2.6.x resulting in presumed 2.4
behaviour (modprobe, udev etc) is the main culprit but there will be more.
Only explore 3.0 if really interested.
2.6.39.1 has an interesting yaffs gotcha - it uses get_sb for superblock
retrieval rather than the more typical mount field. 2.6.39 has dropped the
get_sb field so yaffs is unusable unless patched. My menuconfig2 branch has
such a patch but it may be over simplistic.
2.6.38/2.6.37 series kernels seem fairly bullet proof so it may be safer to
base work on those.
>>> 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.
The userland utilities make assumptions. There are several NOR partitions.
bootldr, params, fpga and kernel (I use an initramfs kernel here,
chainbooting to a "real" one on nand/mmc/usb-mass storage via kexec).
> 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!
I guess you should not change bootldr - that won't help. It may be worth
hiding the bootldr and parameters partition to reduce the chance of
bricking the board. Declare fixed partitions (except kernel) in linux
balloon.c and specify nor mtd support. I guess that you will get a bunch of
preprended mtd partitions. Note that yaffs won't mount on a non-nand
mtdblock (IIRC) so that trampling your first nor mtdblock is actually unlikely.
> 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?
>
Never found one.
> 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.
>
>
There are examples for other boards. I may give it a go myself actually and
put the results in my menuconfig2 branch. Its not too hard and I am having
some time off to do this sort of thing. You could then look at it and
improve/flame the result.
>>> 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."
>
>
Getting fingers dirty is usually a good way tob develop understanding but
does takes an age. Feel free to ask. Your questions are all ok ones.
>>> 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.
>
Make a branch?
>> 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
>
> _______________________________________________
> Balloon mailing list
> Balloon@balloonboard.org
> http://balloonboard.org/mailman/listinfo/balloon
(text/plain)