[Lenny400] JZ4730 and other documentation (was Re: Coin cell on motherboard)

[Paul Boddie]

On Sunday 13. August 2017 21.54.07 H. Nikolaus Schaller wrote:
> 
> I have checked again and it might have been that I mixed it up with chapter
> 18 of the JZ4740 user manual. But AFAIR my I2C driver (for the 3.x kernel)
> did work.

For the JZ4740 or JZ4730? If the former, for which machine? I've read things 
about the I2C implementation for almost all the products in this family that 
have suggested difficulties or bugs. I've run out of patience with this 
peripheral for now, although I might go and whine about it on the CI20 mailing 
lists just to let off some steam. (I doubt there is much more to be said than 
"read the Linux driver source", though.)

> I have found this:
> 
> Jz4740 32 Bits Microprocessor User Manual Revision: 1.0 Date: Jul. 2006
> 
> For the JZ4730 I have:
> 
> Jz4730 Multimedia Application Processor Data Sheet Revision: 1.3 Date: Jul.
> 2007
> 
> and:
> 
> Jz4730 32 Bits Microprocessor Application Notes 001 Clock Revision: 0.9
> Date: Nov. 2006 Jz4730 32 Bits Microprocessor Application Notes 002: the
> used of I2S I2S Controller Revision: 0.1 Date: Jan. 2007

Yes, I think these are the ones floating around on the Internet.

[...]

> No problem. Most likely nobody can. Unless we start to do something.
> Everyone can contribute a tiny piece of information and after some longer
> time we have puzzle pieces that fit.
> 
> In any case we have some quite good sources if information:
> a) the old 2.4 kernel sources (to learn about specific device drivers)
> b) modern jz4740++ Device Tree based implementations
> c) board design guide and schematics
> 
> What we can read from the board design guide/schematics is how to define a
> Device Tree for the minibook.dts (memory, CPU, I2C, RTC, Display,
> UART, Keyboard matrix, ...).
> 
> I have even started such a thing in the Letux-Kernel project but it is not
> very elaborated:
> 
> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/mips/boot/dts/in
> genic/minibook.dts;h=f1b105888c5f70f75bb6817739723bbd1a437806;hb=af482b6f58
> b6c55f7d5efdf76d51d11bf137aaa2

I can have another look at this. A while back I did look at the drivers, but 
it is likely that I understand more of the issues now.

> But maybe a good point to consolidate and collect findings (e.g. keyboard
> mapping). Or just discuss.
> 
> More difficult is to develop a jz4730.dtsi but we could start with an
> (almost) empty one like this:
> 
> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/mips/boot/dts/in
> genic/jz4730.dtsi;h=045d6b291f1e5e735a2bc86702581e2deb7fb184;hb=af482b6f58b
> 6c55f7d5efdf76d51d11bf137aaa2

Yes, this is also something I might have some ideas about. Just to provide 
some background, I was looking at L4Re and Fiasco.OC on the CI20, and I have 
vague hopes of making it work on the Ben NanoNote (which uses the 
JZ4720/JZ4740), and in taking some existing code that I already had working on 
the NanoNote, and then looking at the JZ4780 documentation, it became clear 
that just re-using the JZ4740 code wasn't going to work.

Of course, I realised this before with the JZ4730 and looking at the (at the 
time) mainline Linux kernel sources. But having to restructure my JZ4740 
functionality somewhat (making it use user space addresses mapped to the 
actual physical memory providing the registers), I think I've gained a few 
more insights. It also helps that L4Re has a similar device tree concept, 
although it is actually defined using Lua code wrapping C++ objects, which can 
be a bit tricky to follow at times (especially if you don't know Lua).

> The most difficult thing will be to get a modern kernel emit some console
> messages. Even if it hangs then. This means we must have:
> * U-Boot working

I think my contact who has the Trendtac version of the Minibook (who may even 
be reading this list) was going to look at the JTAG functionality to 
investigate U-Boot but that was a while ago and isn't likely to have been an 
urgent task.

> * startup
> * initialization of MMU, CPU, Clocks
> * UART working
> 
> With this mIlestone it becomes much easier to develop further components.
> 
> Big challenge anyways...

I agree with you here. With the CI20 it's possible to skip the clock 
initialisation by just using the U-Boot provided, although this initialisation 
has been done independently in other projects, so it isn't completely 
mysterious, just tedious. (The same applies to the NanoNote, but I did also 
have USB Boot mode working on that as well, although it seems to have stopped 
working, mysteriously, even with code that worked with it before.)

With the JZ4730, the challenge is, if I remember correctly, finding U-Boot 
source code that corresponds to whatever was installed on the device. Despite 
my struggles with the JZ4780, I don't think that the task of configuring the 
peripherals is really that difficult, just rather time-consuming to test, and 
debugging tools are useful to make that somewhat bearable.

I'll try and formulate the similarities and differences between the JZ4730 and 
JZ4740 a bit better, which may then inform the development of something closer 
to the kernel mainline. As I noted above, I looked at this before, but I 
imagine that the "kernel speedboat" has powered away leaving the things I did 
adrift and obsolete.

Paul

P.S. I do wonder when we might eventually be able to just develop generic 
drivers that can then be run on many different kernels, instead of drivers 
being tightly bound to specific non-portable driver frameworks, especially 
ones that change under everybody's feet all the time.