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

[H. Nikolaus Schaller]

Hi Paul,

> Am 13.08.2017 um 19:05 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Sunday 13. August 2017 18.42.58 H. Nikolaus Schaller wrote:
>> 
>> I haven't seen it either. But AFAIR there were some references to a JZ4730
>> User/Programming Manual. The chip data sheet is still available, e.g.:
>> 
>> 	http://docplayer.net/12271101-Jz4730-multimedia-application-processor-
> data-sheet.html
>> 
>> While trying to locate it I have found this:
>> 
>> 	http://d1.amobbs.com/bbs_upload782111/files_25/ourdev_532550.pdf
>> 
>> which might also give some background on the hardware.
> 
> I have seen a similar "board design guide" document before, although this may 
> be a slightly later and slightly different version.
> 
> The one kind of document that is stubbornly absent is the programming manual, 
> though, which is why I believe that it must have been kept internal for some 
> reason, or maybe it never existed as such. Sites similar to those above will 
> probably yield the programming manuals for all of the other SoCs in that 
> product family, but I doubt that you'll ever find one for the JZ4730.
> 
> [...]
> 
>> I remember that I had some application note (?) for I2C to write a new i2c
>> driver long time ago. But I didn't find it or a copy any more. Seems to
>> have gone in digital deletion.

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.

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

> 
> Well, I think this is mostly an issue of my own comprehension plus annoyingly 
> underdocumented hardware. To be fair, having looked at Microchip documentation 
> not that long ago, and despite that being a very established company with a 
> long record of writing things down for others to work from, I think there's a 
> growing disconnect between the engineering departments and the people given 
> the job of describing the product.
> 
> Anyway, as I noted, I have been looking at the JZ4730 and trying to make some 
> sense of it, and some progress with the JZ4740 (and even JZ4780) means that I 
> probably have a slightly better idea about some of the things that I was 
> mostly guessing at before. That isn't to say that I can necessarily write 
> coherent Linux driver code, though.

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/ingenic/minibook.dts;h=f1b105888c5f70f75bb6817739723bbd1a437806;hb=af482b6f58b6c55f7d5efdf76d51d11bf137aaa2

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/ingenic/jz4730.dtsi;h=045d6b291f1e5e735a2bc86702581e2deb7fb184;hb=af482b6f58b6c55f7d5efdf76d51d11bf137aaa2

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
* startup
* initialization of MMU, CPU, Clocks
* UART working

With this mIlestone it becomes much easier to develop further components.

Big challenge anyways...

BR,
Nikolaus