[Lenny400] Slightly later kernel/distro version

H. Nikolaus Schaller hns at goldelico.com
Fri Sep 1 12:13:38 CEST 2017

Hi Paul,

> Am 01.09.2017 um 12:03 schrieb Paul Boddie <paul at boddie.org.uk>:
> On Friday 1. September 2017 10.51.07 H. Nikolaus Schaller wrote:
>>> Am 31.08.2017 um 23:18 schrieb Paul Boddie <paul at boddie.org.uk>:
>>> So, I have more recently been writing drivers and things for the
>>> linux-stable branch (4.13-rc5 or so).
>> Wow!!!
> Only if it eventually works. ;-)
>>> The JZ4740 maintainers have mostly laid the
>>> foundations,
>> that is what I would expect.
>>> although there are some areas where the functionality differs
>>> enough that it requires some careful reimplementation or adjustment...
>> The SoC are not the same but cousins and share a lot of things.
> Yes. It does help that the CI20 support code has appeared in various places, 
> meaning that the JZ4780 is also supported and can provide some guidance about 
> how to support multiple SoCs within the same code.
>>> The relationship between clocks, PLLs and peripherals is different,
>>> meaning that a special CGU driver is required. I did see something odd
>>> about the JZ4740 support, but I haven't managed to follow up with the
>>> MIPS developers about this.
>>> The JZ4730 has dedicated PWM peripherals, meaning that the TCU-based
>>> JZ4740 driver cannot be used and a separate one needs to be introduced.
>> Ok, but IMHO PWM is not on highest priority.
> It is needed for the backlight, although I suppose some quick register writes 
> could be done to set that up.

Maybe it is possible to simply turn it on by gpio-pinmux...

> Still, writing this driver should be a 
> relatively simple exercise that provides a learning experience, and so I have 
> made an effort to do so, making mistakes on the way, of course.
>>> Also, the JZ4730 doesn't have a TCU (timer/counter unit) but an OST
>>> (operating system timer) instead, so the timer support needs providing
>>> in a different way.
>> Ok.
>>> The GPIO management is different on the JZ4730. This was something I
>>> attempted to tackle before, but I have mostly verified my understanding
>>> now, and so JZ4730 support needs to be introduced to both the GPIO and
>>> pinctrl drivers.
>> GPIO and Pinmux this seems to be one of the most essential components
>> besides Clock & Power & Reset managers. With that it should be possible to
>> see a little more than Starting kernel ...
> I will look at the LCD/framebuffer code. This was always common between the 
> different SoCs and only really had noticeable divergence around relatively 
> trivial things like clock initialisation, which should have minimal impact if 
> those things have been abstracted sufficiently.

Ok, so it should not be one of the biggest challenges.

>> Another significant component is MMU. Or is this already done by the MIPS
>> core code?
> That should be at the MIPS core level, and I don't think there are any 
> significant differences between the JZ4730 and JZ4740 here.


>>> It seems possible that a special keypad driver is no longer needed in the
>>> modern kernel because a generic GPIO keypad driver can be used. The data
>>> structures for the keypad need changing slightly to work with this. I
>>> don't know how things like Num Lock and Caps Lock are supported in this
>>> arrangement, however.
>> Yes, the modern matrix driver should be good enough:
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-mat
>> rix-keypad.txt
>> And if not, we could still write our own on top of the gpio library
>> functions of modern kernels.
>> I think Num Lock and Caps Lock are to be handled by user-space (X11). The
>> kernel events only tell that the key was pressed/released.
> I guess that there might be a mapping somewhere that was previously done by 
> some code that used a switch statement to convert between the different key 
> labels.

Yes, the original jzchar driver did a lot of magic which should be done
completely different with modern kernels.

>>> Board initialisation needs changing to work with the modern kernel. This
>>> mostly seems to involve choosing the appropriate devices and wiring them
>>> up correctly.
>>> Device tree definitions are also needed for the JZ4730 and the Minibook.
>> I have started something a little - but it is quite empty and probably
>> wrong:
>> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/mips/boot/dts/in
>> genic/jz4730.dtsi;h=045d6b291f1e5e735a2bc86702581e2deb7fb184;hb=400a68db3ff
>> 8f78fde56b3f9bc904f01a0f951ef
>> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/mips/boot/dts/in
>> genic/minibook.dts;h=5b378e548cacbf341705d7575881c2d7691d9c88;hb=64931d3074
>> f0abd59c808c692321e8b796520e77
>> This is an area where I probably can help a lot.
> I've expanded those quite a bit.

If you have a newer version, I can simply add it so that we can show it around...

>>> So far, I have made an attempt to implement all of the above: CGU, PWM,
>>> timer, GPIO, board and device tree functionality.
>> Yes, this is necessary to see it booting (maybe PWM isn't needed here).
>> Ah, and we need UART for console log (and potentially login:).
> UART should be very similar between the JZ4730 and JZ4740, if not practically 
> identical.

Ok, fine!

>>> Remaining things in approximate
>>> order of descending necessity are likely to be watchdog timer, RTC,
>>> LCD/framebuffer, MMC, generic DMA (maybe used by the MMC support), I2C,
>>> USB, sound and NAND functionality.
>> I'd see this priorities (DMA whenever we really need it):
>> * UART console
>> * MMC (to be able to run a rootfs)
>> * I2C to be able to access RTC and PMU
> Since I was looking at the RTC support yesterday, maybe I need to evaluate 
> this again.

IMHO, the RTC is simply an nxp,pcf8563 which has a modern driver:


So having a SoC I2C master driver is the limitation.

>> * USB to have more peripherals and external memory expansion
>> * LCD to see something and run X11
>> * Keyboard (gpio-matrix based)

What I am no longer finding is the nice documentation of the gpios on kwaak...
Do you have a link to that? Then I could set up something from documentation

>> * LED drivers (AFAIR some gpios)
>> * WDT
> I was also looking at the watchdog timer yesterday as well.
>> * sound
>> * NAND
>>> Without getting as far as LCD/framebuffer support and maybe MMC, I'm
>>> doubting that I can really test this at the moment. But I wonder if
>>> anyone else is interested in seeing what I've done and maybe pointing
>>> out errors in the way I've done some things.
>> Yes, please share for discussion.
> I'll try and put together some patches and maybe send them to the list.

Fine! Then I can try to integrate them into the Letux kernel tree.


More information about the Lenny400 mailing list