Paul Boddie | 21 Apr 23:02 2015
Picon

Re: [Lenny400] jz4740.dtsi (JZ4730 DT upstream)

On Tuesday 21. April 2015 22.40.59 Paul Burton wrote:
> On Mon, Apr 20, 2015 at 12:47:04PM +0200, Paul Boddie wrote:
> > 
> > It's great to see the custodian of the architecture focusing on getting
> > the Ingenic SoCs fully supported in the mainline kernel. This benefits
> > everyone!
> 
> Absolutely, and help with supporting more SoCs is definitely welcome :)

Well, I'm a novice in this respect, but I can certainly try and help out in 
various ways.

> >From a quick google it appears there are a lot of variants of JZ4730
> 
> netbook, which is pretty cool! Do you happen to know whether any of them
> are still available to buy anywhere?

Nikolaus is still selling jz4730-based netbooks as the Letux 400 with a 2.6-
based Linux distribution pre-installed. See...

http://shop.goldelico.com/wiki.php?page=Letux%20400

[...]

> You may be interested in the revised series I submitted earlier today to
> support the JZ4780, which is what's also present in that (often rebased)
> branch on github:
> 
>   http://www.linux-mips.org/archives/linux-mips/2015-04/msg00284.html

(Continue reading)

Paul Boddie | 20 Apr 12:47 2015
Picon

Re: [Lenny400] jz4740.dtsi (JZ4730 DT upstream)

On Monday 20. April 2015 10.52.13 Zubair Lutfullah Kakakhel wrote:
> 
> On 19/04/15 10:38, Dr. H. Nikolaus Schaller wrote:
> > 
> > The community behind the mailing list on CC: is interested on doing a
> > similar step for the jz4730 (even if it is old and out of production
> > there have been some nice 7 inch Mini-PCs/Subnotebooks around this SoC).
> > 
> > And we want to build upon your work to avoid that we start something
> > incompatible.
> 
> Thank-you for contacting us. Upstream work should definitely be
> collaborative.

It's great to see the custodian of the architecture focusing on getting the 
Ingenic SoCs fully supported in the mainline kernel. This benefits everyone!

> > So I wonder what the latest status/plans are for getting jz4740.dtsi (and
> > related rework) upstream?
> 
> See this for the latest work on jz4780 and jz4740.
> 
> https://github.com/paulburton/linux/tree/wip-ci20-v4.1
> 
> Our focus is on jz4780 and MIPS Creator CI20 support upstream.
> 
> We are working on jz4740 for maintaining compatibility.

I see that there's support for jz4770/jz4775, too. Is it also a priority to 
get this upstream?
(Continue reading)

Riccardo Mottola | 20 Apr 09:44 2015
Picon

GNUstep check

Hi,

just as an update. Still using old 2.4 kernel and old Debian with FPU emulation, I did a complete rebuild of GNUstep packages.

Good news: everything appears to (still) work. I tried most userland applications and, except the slugginess, MIPS seems to be in good shape.

If you guys sort out a newer kernel, the concept of a clean userland using a native build without FPU could be interesting. I wonder if Debain is still the way to go though, due to the gradual adoption of systemd. For now, luckily, you remove it and work it, as I did on my PPC.

Riccardo
<div><div dir="ltr">Hi,<div><br></div>
<div>just as an update. Still using old 2.4 kernel and old Debian with FPU emulation, I did a complete rebuild of GNUstep packages.</div>
<div><br></div>
<div>Good news: everything appears to (still) work. I tried most userland applications and, except the slugginess, MIPS seems to be in good shape.</div>
<div><br></div>
<div>If you guys sort out a newer kernel, the concept of a clean userland using a native build without FPU could be interesting. I wonder if Debain is still the way to go though, due to the gradual adoption of systemd. For now, luckily, you remove it and work it, as I did on my PPC.</div>
<div><br></div>
<div>Riccardo</div>
</div></div>
Dr. H. Nikolaus Schaller | 19 Apr 11:38 2015

jz4740.dtsi

Hi,
we have seen that you had submitted a for the jz4740 to make it device tree compatible, as the basis to make the
jz4780 work:

	http://patchwork.linux-mips.org/patch/9193/

Some of your other patches have appeared in linux-next and will likely come to 4.1-rc series in the next weeks.

The community behind the mailing list on CC: is interested on doing a similar step for the jz4730
(even if it is old and out of production there have been some nice 7 inch Mini-PCs/Subnotebooks around this SoC).

And we want to build upon your work to avoid that we start something incompatible.

So I wonder what the latest status/plans are for getting jz4740.dtsi (and related rework) upstream?

BR and thanks,
Nikolaus Schaller

Dr. H. Nikolaus Schaller | 7 Apr 13:32 2015

Kernel git

Hi,
as promised I have set up a kernel repo (well it did already exist so that it is just another branch):

http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/wip/letux400

I have rebased it on top of the gta04 variant of 4.0.0-rc7 (to simplify my work :), but I think 
it is not difficult to rebase it on top of linus/master.

So far we have 3 patches on top:
* Paul’s jz4730 work
* Daniel’s PM MCU driver
* I have copied in the jz4740.dtsi, made a jz4730.dtsi out of it and added a minipc.dts

So we get a still very useless DT binary :)

http://download.goldelico.com/letux-400/unstable/device-trees.tbz

BR,
Nikolaus

Dr. H. Nikolaus Schaller | 5 Apr 19:34 2015

jz47xx Device Tree

After doing some more research, I think the status of MIPS DT is even more advanced than I had thought:

1. 4.0-rc already supports a handful of DT based MIPS CPUs:
	https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/boot/dts?id=refs/tags/v4.0-rc6

2. there are patches circulating on LKML to convert jz4740 to DT:
	https://lkml.org/lkml/2015/2/4/392

	unfortunately they did end up - as far as I can see - in a social issue (within imgtec?)
	https://lkml.org/lkml/2015/2/4/463

	There has been some more activity here:
	https://patchwork.kernel.org/project/LKML/list/?q=jz4780

	Some of these patches have already appeared in linux-next (so they will become part of 4.1-rc1 in ca. 4 weeks):
	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=refs%2Ftags%2Fnext-20150402&qt=grep&q=jz4740

	Driver for his activity is the JZ4780 CI20 board: http://www.elinux.org/CI20_upstream
	e.g. https://github.com/MIPS/CI20_linux/blob/ci20-v3.18/arch/mips/boot/dts/jz4740.dtsi

	The really good thing is that this is done more or less officially by Imgtec - so there is manpower behind.

Since we now know that the jz4730 also has some similarities as well, we should IMHO try to help to get the
jz4740 DT patches upstream. Instead of tweaking the non-DT jz4740 code and #include like Paul’s patch
does .
Which might then lead soon (3-6 months?) to merge conflicts with linus/master.

And just add our own jz4730.dtsi and jz4730-minipc.dts and some jz4730 specific drivers.

Seems to be easier and future-proof for me than starting to work on any non-DT code.

But we should definitively use Paul’s patch as the basis for understanding what we have to change from
jz4740 to jz4730.

What do you think?

BR,
Nikolaus

Dr. H. Nikolaus Schaller | 5 Apr 19:24 2015

jz47xx Device Tree

After doing some more research, I think the status of MIPS DT is even more advanced than I had thought:

1. 4.0-rc already supports a handful of DT based MIPS CPUs:
	https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/boot/dts?id=refs/tags/v4.0-rc6

2. there are patches circulating on LKML to convert jz4740 to DT:
	https://lkml.org/lkml/2015/2/4/392

	unfortunately they did end up - as far as I can see - in a social issue (within imgtec?)
	https://lkml.org/lkml/2015/2/4/463

	There has been some more activity here:
	https://patchwork.kernel.org/project/LKML/list/?q=jz4780

	Some of these patches have already appeared in linux-next (so they will become part of 4.1-rc1 in ca. 4 weeks):
	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=refs%2Ftags%2Fnext-20150402&qt=grep&q=jz4740

	Driver for his activity is the JZ4780 CI20 board: http://www.elinux.org/CI20_upstream
	e.g. https://github.com/MIPS/CI20_linux/blob/ci20-v3.18/arch/mips/boot/dts/jz4740.dtsi

	The really good thing is that this is done more or less officially by Imgtec - so there is manpower behind.

Since we now know that the jz4730 also has some similarities as well, we should IMHO try to help to get the
jz4740 DT patches upstream. Instead of tweaking the non-DT jz4740 code and #include like Paul’s patch
does .
Which might then lead soon (3-6 months?) to merge conflicts with linus/master.

And just add our own jz4730.dtsi and jz4730-minipc.dts and some jz4730 specific drivers.

Seems to be easier and future-proof for me than starting to work on any non-DT code.

But we should definitively use Paul’s patch as the basis for understanding what we have to change from
jz4740 to jz4730.

What do you think?

BR,
Nikolaus

Dr. H. Nikolaus Schaller | 4 Apr 19:30 2015

Re: [Lenny400] Some tentative changes to the mainline kernel

Hi Paul,

Am 04.04.2015 um 15:04 schrieb Paul Boddie <paul@...>:

> On Saturday 4. April 2015 14.23.59 Dr. H. Nikolaus Schaller wrote:
>> 
>> 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?
> 
> No, I can only provide the changeset:
> 
> commit a39bdfb590f54d0f41d6a5b352b085322d007dcd
> Merge: a7fe850 ae6ee2f
> Author: Linus Torvalds <torvalds@...>
> Date:   Fri Mar 27 14:45:42 2015 -0700
> 
>    Merge git://www.linux-watchdog.org/linux-watchdog
> 
>> Then we can quite easily rebase to 4.0-rc6 and merge things together.
> 
> Given that the starting changeset was just after a merge from 4.0-rc6, that 
> shouldn’t be too difficult.

I have checked out the base commit and applied your patch and I am really impressed:

arch/mips/boot/uImage: u-boot legacy uImage, Linux-4.0.0-rc5+, Linux/MIPS, OS Kernel Image (gzip),
2753935 bytes, Sat Apr  4 19:22:25 2015, Load Address: 0x80010000, Entry Point: 0x803E98A0, Header CRC:
0xEE3F7379, Data CRC: 0xC81DF3D8

So we have a great starting point. At least it compiles :)

Kudos to Paul!

Next I will add Daniel’s patch and if you agree I will add your “Signed-off”.

I assume Linux will publish 4.0.0-rc7 on Monday/Tuesday. Then I will upgrade (merge)
and publish the results.

Maybe for simplicity I will merge the MIPS work with the GTA04 ARM work,
since they should not interfere and just having one branch for multiple machines
is the easiest. I will keep you updated where the tree finally is :)

BR,
Nikolaus

Daniel Glöckner | 4 Apr 18:42 2015
Picon
Picon

Re: [Lenny400] Some tentative changes to the mainline kernel

Hi,

No Signed-off-by line?

On Sat, Apr 04, 2015 at 02:15:57PM +0200, Paul Boddie wrote:
> If anyone can see any obvious things that prevent these changes from
> making a bootable kernel, I'd be very pleased to hear about them.

You need a spinlock to prevent a race condition when two processes
want to access the GPIOs at the same time. That's why they introduced
set and clear registers in the 4740.

For reading the battery voltage and powering off the device, you can
use the driver from the following mail. I used it with the 2.6.31
Kernel (after fixing the non-standard API of the I2C driver).

The Linux 2.4 USB gadget driver for the 4730 looks completely different
from the 4740 driver. I don't think is uses the same IP core.

If the plan is to eventually switch to DT, it must be possible to
compile a kernel that can handle both the 4740 and the 4730. So
defining macros to different values depending on the processor is
not an option.

Best regards,

  Daniel

Dr. H. Nikolaus Schaller | 4 Apr 14:23 2015

Re: [Lenny400] Some tentative changes to the mainline kernel

Hi Paul,

Am 04.04.2015 um 14:11 schrieb Paul Boddie <paul@...>:

> 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 <paul@...>:
>>> 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

Dr. H. Nikolaus Schaller | 4 Apr 10:34 2015

Re: [Lenny400] Some tentative changes to the mainline kernel

Hi Paul,

Am 04.04.2015 um 02:34 schrieb Paul Boddie <paul@...>:

> 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
> Lenny400@...
> http://lists.goldelico.com/mailman/listinfo.cgi/lenny400


Gmane