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. > , with some additional > patches for the NanoNote still required for successful operation (backlight, > keymap, some NAND stuff). Note that the NanoNote uses the jz4720, but it is > mostly a repackaged jz4740 as I understand it. > > So, switching to the jz4730, I had a look at the existing letux-400 2.6 > kernel > as well as various datasheets floating around on the Internet. I asked on the > #qi-hardware IRC channel on FreeNode for a bit of advice on the best way to > support the jz4730 in general, as well as pointers to support for other > jz47xx > variants. I found the following things: > > 1) https://github.com/gcwnow/linux/tree/jz-3.19/arch/mips > 2) https://github.com/MIPS/CI20_linux > 3) http://git.ingenic.cn:8082/gerrit/android/kernel/kernel-3.0.8/ Interesting! > > First of all, none of these things supports the jz4730 as it is just too old > and forgotten for people to bother with, and my impression is that it is also > the "odd one out" in the jz47xx series (Ethernet, PCMCIA, PS/2 support!) with > not even a programming manual floating around on the Internet. However... > > (1) attempts to support the jz4770 for the GCW-Zero handheld console. The > opinion on #qi-hardware was that the way the jz4770 is accommodated is "the > wrong way” by adding a mach-jz4770 directory. 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). > > (2) attempts to support the MIPS Creator CI20 and the jz4780, which is > apparently done "the right way" by not adding a mach-jz4780 directory. ;-) I > cannot believe, however, that this actually produces a working kernel for > that > board given that various essential files are missing. > > (3) is actually only accessible from git directly, not via a browser, and > contains the Ingenic-maintained ancient kernel which also doesn't support the > jz4730 and definitely wouldn't be considered "the right way" by anyone > committing stuff for the mainline kernel. > > Having looked at all this, I started seeing if I could accommodate the jz4730 > within the jz4740 mainline support without creating lots of new files that I > would then have to populate. Although there are some similarities between the > two CPUs, meaning that some details can be shared, there are also some > crucial > differences that would probably hinder any kind of success if any of them are > missed or misinterpreted. > > For the most part, the two CPUs keep their registers in similar memory > regions, and where a jz4740 region is differently labelled in the 2.6 kernel > for the jz4730, it doesn't seem to be of significance to either kernel. (I > think it was just the region at 0x10002000 but not the critical timer/counter > region at 0x10002010.) The GPIO registers seem to use a different layout, > however, occupying blocks every 48 bytes in the jz4730 instead of every 256 > bytes in the jz4740, mostly because the jz4730 seems to employ modifiable > registers instead of the separate read/set/clear registers in the jz4740. > This > meant that I had to split the GPIO code in arch/mips/jz4740 into separate > versions. > > The GPIO/pin definitions do differ between the two CPUs according to the > datasheets, and this is confirmed in the 2.6 kernel when compared to the > mainline jz4740 support. Thus, a separate set of definitions needs to be > provided in arch/mips/include/asm/mach-jz4740 for the jz4730 and jz4740 > (which > involves some header file indirection that may not be “the right way"). 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. > GPIO > operations in the mainline kernel are apparently done using a framework that > is cleaner but less concise than the #defines found in the jz4730 support > from > the Ingenic 2.6 kernel. Here, the different nature of the GPIO registers is > apparent, and the idea is to somehow replicate them in the mainline > framework. > Moreover, the 2.6 kernel does some quick-and-dirty initialisation in the > board > file for the minipc/Letux400 that is done in part by various frameworks in > the > mainline kernel (framebuffer, PWM) but not by everything (USB, I2S). > > Interrupt/IRQ definitions also differ between the two CPUs, although I remain > uncertain about things like DMA and what interrupt support there is for that. > In addition, the GPIO register changes impact various IRQ-related operations: > some jz4730 registers appear to combine the functionality of two jz4740 > registers. Again, some header file indirection is used to switch to the > appropriate definitions without breaking the drivers needing to know about > the > jz4740. I think for getting things started your approach seems to be the right one. > > I have the faintest hope that the jz4740 framebuffer support will manage to > handle the jz4730 and the display used by the Letux400. I think it may be > sufficient to configure the structure appropriately and just make sure that > the driver uses the right pins, requiring the correct definitions and also > some minor (and maybe superfluous) changes to the driver. Similarly, the > backlight might be supported by the PWM backlight driver, again given the > appropriate pin definitions. I noticed that PWM is driven via some registers > in the jz4730 that do not appear to be documented for the jz4740 or used by > the mainline kernel code, but it seems possible to use the jz4740 mechanism > instead which employs the timer/counter unit. Backlight wouldn’t be my main concern in the beginning. It could just be turned always on - until the main parts are working. > > 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. > 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'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). So you are welcome to submit your patches to this list here and I can integrate it into git. BR, Nikolaus > > Paul > _______________________________________________ > Lenny400 mailing list > lenny...@goldelico.com > http://lists.goldelico.com/mailman/listinfo.cgi/lenny400 _______________________________________________ Mipsbook-devel mailing list Mipsbook-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
