Hi Jamie,
Jamie Lokier wrote:
Greg Ungerer wrote:
Last time i tried it the build was broken and someone admitted it
was not maintained since the last attempt 2.6.14?
non-MMU ARM has never be in mainline, not in 2.6.14, not ever.
I have been keeping and updating patches (kept in the uClinux-dist
linux-2.6.x sources).
On 13 Mar 2008, you wrote:
I have been working from each new linux-2.6 series kernel
to get the ARM non-mmu support integrated into mainline (working
through RMK to get this done). It has been a slow process, and
it is not quite complete yet. I would say it is 95% of the way
there though. It is close to the basic support being in mainline
kernels.
Please can you clarify: I have a couple of questions. (Look for
question marks if these is too long).
Is the _intention_ to have no-mmu ARM working in mainline 2.6 kernels,
but that has not yet been achieved?
Yes, that is right.
I find the ARM maintenance situation very confusing. I don't know
where I should look find a good working no-mmu ARM tree, even if it's
a little old.
What might be best to use will vary depending on what your
exact target is. I am only keeping the AT91x40 working in -uc.
If you where using an NXP LPC288x part then Lucy Wang recently
posted patches (on top of -uc patches) for those (that was
for 2.6.21 IIRC). For other SoC parts you may need to go back
to Hyoks patches for something that works better.
Note that it is the SoC support parts that is the issue. The
core no-mmu support is working through most of 2.6.x series
kernels with the -uc large (which is part of the uClinux-dist)
patchset.
I do need features found in current 2.6 kernels (and want to track
those - indeed, to contribute to them while using them on my board)
and I'm afraid of ending up maintaining _yet another_ ARM tree which
gets on with the merging/implementation job, fragmenting even further
and duplicating others' not easily found work.
For example, say I need to make some core kernel changes (MTD, VFS or
blkdev) to 2.6 to support my no-mmu ARM application. Clearly this is
much more difficult if my ARM board can only run rather old heavily
patched non-mainline kernels, while I'm trying to interact with
MTD/VFS/blkdev people who develop using kernels close to current
mainline.
For sure. And that is why I want to get the last peices of the
non-MMU ARM support into mainline.
But then, from linux-arm-kernel, perhaps it's not surprising:
Right, as a result of the recent debacle, and lets face it, utter
disaster with the ARM tree, I'm going to become far more strict in the
future, and re-impose the requirement that all development changes must
be in my git tree (actually merged) by the time that Linus starts the
merge window.
What Russell is talking about here has no bearing on getting
no-mmu support for ARM into mainline. It is purely about the timing
of him applying patches for inclusion into mainline.
You say (I think) to use -ucN big patches for ARM no-mmu work, but
other things are written elsewhere.
Yes. In the past I haven't always folded the latest arm non-mmu
patches into the small -uc0 kernel patch set. The patches in that
set are the ones I send direct to Linus (usually core no-mmu changes
and m68knommu). All my ARM changes go through rmk - and usually
I haven't finished them when I generate -uc0.
But the large diff includes all kernels changes that are in the
2.6.x kernel of uClinux-dist.
Google ARM Linux brings mixed
results and old FAQs.
There is a lot of fragmentation in the uClinux space.
Following this list is the best advice I can give.
I can comment on specific pages/links if you post them here.
In practice, I've been using the -ucN patch
with 2.4 kernels - very helpful, thank you. I don't want to sound
ungrateful, I'm just confused about where I should be putting my own
efforts. My own SoC requires lots of patches itself - I am used to
starting with a relatively generic kernel, and maintaining local SoC
patches on top of it.
That is not a bad strategy. And I expect will be the common mode
of operation. It is the individual SoC support that takes most
effort, and generally needs to be done by those who have the
hardware.
Now that generic nommu support is _nominally_ in the mainline kernel,
it seems odd to me that the mainline kernel + SoC patches is not what
I'm supposed to be doing.
That is your starting point. Ideally when you are happy with your
specific SoC support you generate patches and we can get them
merged into mainline.
I realise the situation was different with
2.4, because nommu wasn't in mainline 2.4.
Is it the long term goal that a system developer would, eventually,
get the mainline kernel + their own SoC patches and that should be
sufficient - as it is with many of the architectures already?
I would hope the long term goal is to get your full SoC support
into the mainline kernel. Yes it could take quite some work to
do this.
(Getting -ucN or -rmkN or whatever patches to try things before they
are merged and so on is different, I'm not asking about that, I'm
asking if the intention is that everything which isn't
board/SoC-specific will be merged into mainline at the usual rate and
methodology for other (non-uclinux) architectures?)
In a perfect world everything would be mainlined.
This may seem like an odd question, but I have been under the
impression that, at least for 2.4 kernels, both yourself and Russell
King believed in not keeping all the essential uclinux/ARM patches in
mainline kernels. So I guess I can summarise: has that policy
changed, to be more in keeping with general 2.6 development practice?
Absolutely. The goal is mainline everything. With 2.4 there was
no core non-mmu support for anything. It made no sense to mainline
non-MMU architecture code with no core support.
With 2.6 I/we are trying not to live outside mainline with large
patchsets. The patch sets are for testing and evaluation, to get
the code right before submission.
Hope that helps...
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
