[Lenny400] JZ4730 and other documentation (was Re: Coin cell on motherboard)
paul at boddie.org.uk
Tue Aug 15 00:57:02 CEST 2017
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.
> 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:
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:
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
> * 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.
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.
More information about the Lenny400