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

H. Nikolaus Schaller hns at goldelico.com
Tue Aug 15 10:04:53 CEST 2017


Hi Paul,

> Am 15.08.2017 um 00:57 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> 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?

for the 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.)

Here I have found it (I should better remember our own archives...):

http://git.goldelico.com/?p=letux-400.git;a=shortlog

AFAIR this ended in a working i2c driver.

> 
>> 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).

Maybe the jz4730 is in between the jz4720 and jz4740? Which means some peripherals
of the SoC are still like jz4720 and some are reused on jz4740.

This is wild speculation but could be conjectured how VHDL development projects
usually work to reduce the amount of work.

> 
>> 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.

Well, that is developer's dream :) It requires stable API around pure drivers.
In my observation this has become much better in Linux since DT and devm_ was
introduced. So the kernel API got a little more object-oriented programming
style.

BR,
Nikolaus



More information about the Lenny400 mailing list