Hi Paul, Am 04.04.2015 um 14:11 schrieb Paul Boddie <p...@boddie.org.uk>:
> On Saturday 4. April 2015 10.34.58 Dr. H. Nikolaus Schaller wrote: >> Hi Paul, >> >> Am 04.04.2015 um 02:34 schrieb Paul Boddie <p...@boddie.org.uk>: >>> Hello, >>> >>> I was recently persuaded (or managed to convince myself) to take a look >>> at building a kernel for the Letux400, already having a Ben NanoNote and >>> wanting to see if I could build a mainline kernel for that. It turned >>> out that the jz4740 support in the mainline is mostly complete >> >> yes, it looks to be quite mature - but the only jz47xx chip that is >> supported at all. > > Yes, as I understand it, some very motivated people managed to get the > jz4720/jz4740 support ported to the mainline kernel APIs a while ago. Yes, there seems to be quite some stuff here: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/jz4740?id=refs/tags/v4.0-rc6 But I don’t know how far it is compared to all the work-in-progress trees. > Certainly, support for 3.12 started here: > > http://lists.en.qi-hardware.com/pipermail/discussion/2013-November/010406.html > > And this work has continued right through last year: > > http://lists.en.qi-hardware.com/pipermail/discussion/2014- > September/010705.html > > There were surely many previous releases that I wasn't paying attention to. > ;-) > > [...] > >> I think there should be a mach-jt47xx directory. Like for ARM there is >> arch/arm/mach-omap2 (covering OMAP2, OMAP3, OMAP4, OMAP5 >> and at least 30 different variants). > > I don't know the reasoning for the objection to a separate mach-jz4730 > directory. Maybe it just seems like unnecessary proliferation of directories! Or they argue that all jz processors should share a directory - as long as they are reasonably similar. > > [...] > >> OMAP has the same “problem”. The number and base addresses of the >> GPIO controllers differ. >> >> It is solved by a mixture of code and the device tree. The DT can specify >> different base addresses and the number of gpio controller instances. And >> can control through the “compatible” property how the driver uses these >> addresses to cover such differences. >> >> But we have no DT in MIPS. Or would it be possible to just use introduce it >> for the JZ chips? Basically DT is not restricted to a specific >> architecture. Except by really using it. > > The MIPS Creator kernel developers are supposedly going to introduce DT > support, and various branches in various repositories also promise such > support. For instance, the qi-kernel repository appears to have a branch for > 3.18 with DT support, although it is likely to be a work in progress: > > http://projects.qi-hardware.com/index.php/p/qi-kernel/source/tree/jz-3.18-dt/ Oh nice! So it will come in 3-4 iterations. > > [...] > >> Backlight wouldn’t be my main concern in the beginning. It could just be >> turned always on - until the main parts are working. > > Yes, U-Boot seems to take care of this, anyway. > >>> Since my patch isn't very large, I intend to send it to this list, >>> although I suppose I could also push it or share it somewhere. >> >> Yes, it is no problem to send it to this list. > > OK, I’ll send a separate message with the entire set of changes. Great. > >>> I rather dislike git and >>> don't have a GitHub account, so I can't claim to be seamlessly >>> interoperable with those who like both those things, but I will >>> cooperate with anyone who wants to correct my work and to test it. I >>> also don't tend to work with the Linux kernel, so you can probably also >>> expect lots of mistakes and bad practices. ;-) >> >> What I can offer is that we update the l400 branch of the gta04 kernel >> (http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/3.12- >> wip-letux400) and at some point it can simply be merged into the gta04 >> master branch and continued to be maintained (and upstreamed) there. >> >> BTW: it is mirrored to github, so it will be there as well: >> >> https://github.com/goldelico/gta04-kernel/tree/3.12-wip-letux400 > > I don't really mind where the patch ends up, but note that I started from > "torvalds/linux" meaning that it branches out from a very recent kernel, not > from the above branch, although I did see that before and decided not to > start > with it. (I don't think the Letux400 functionality is really combined with > the > rest of the code, is it?) No, they should be quite independent. The branch above is a torvalds/linux plus approx. 140 differences to make it work on the GTA04. And we regularily merge in linus/master so that we keep up to date. Do you know which exact release (tag) you did base your work on? Then we can quite easily rebase to 4.0-rc6 and merge things together. > >>> I'd like to see the jz4730 supported in the mainline kernel or a close >>> derivative because it would also give me some confidence that other >>> jz47xx variants would be sustainable choices for new hardware. For >>> instance, the EOMA68 initiative intends to produce hardware using the >>> jz4775 that could even be considered "FSF-endorseable", and it just >>> isn't sustainable to use these "code drop" ancient kernels that Ingenic >>> seems to provide for the basis of a software distribution or for >>> anything needing a reasonable period of support. >> >> Yes, this matches with the ideas I have for the gta04-kernel. It should >> (and is already not) focussed on the GTA04 device any more (it already >> supports the OpenPandora and Pyra Handheld, as well as the BeagleBoards). >> So iot is more and more becoming a maintained “distribution kernel”, i.e. >> adds some parts on top of kenrel.org to make it useful for daily work. >> And, we regularily try to upstream things to kernel.org (which is >> sometimes tough work). > > I foresee a lot of difficulty trying to get stuff into the "proper" kernel, > especially with the continuous churn, and the DT stuff will be the next > hurdle > to overcome after people decide that any new functionality must use DT. Yes, of course. But I think the biggest hurdle is to start :) > But I > feel that as long as we start out a lot closer to the current state of > development, we have a chance of merging, and if we are able to make as much > use of existing functionality as possible, the patches shouldn't be very > controversial at all. > >> So you are welcome to submit your patches to this list here and I can >> integrate it into git. > > Expect a message with these shortly! :-) Great! I can wait some more minutes :) BR, NIkolaus _______________________________________________ Mipsbook-devel mailing list Mipsbook-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
