Send Mipsbook-devel mailing list submissions to
mipsbook-devel@linuxtogo.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
or, via email, send a message with subject or body 'help' to
mipsbook-devel-requ...@linuxtogo.org
You can reach the person managing the list at
mipsbook-devel-ow...@linuxtogo.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Mipsbook-devel digest..."
Today's Topics:
1. Re: [Lenny400] jz4740.dtsi (JZ4730 DT upstream) (Paul Boddie)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Jun 2015 23:52:39 +0200
From: Paul Boddie <p...@boddie.org.uk>
To: lenny...@goldelico.com
Cc: mipsbook-devel@linuxtogo.org
Subject: Re: [Mipsbook-devel] [Lenny400] jz4740.dtsi (JZ4730 DT
upstream)
Message-ID: <201506292352.39398.p...@boddie.org.uk>
Content-Type: Text/Plain; charset="windows-1252"
On Sunday 28. June 2015 19.35.12 Dr. H. Nikolaus Schaller wrote:
Hi all,
Am 28.06.2015 um 12:21 schrieb Dr. H. Nikolaus Schaller <h...@goldelico.com>:
Today is a good day for the MiniPC / jz4730 based devices :)
Linus has merged the jz4740.dtsi
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?i
d=78c10e556ed904d5bfbd71e9cadd8ce8f25d6982
into linus/master.
So the infrastructure for writing a jz4730.dtsi and adapting drivers
where needed is here.
I have plugged together sort of a sketch:
http://git.goldelico.com/?p=gta04-
kernel.git;a=shortlog;h=refs/heads/work/hns/arch/mips/jz4730
Thanks for keeping an interest in this!
Here some notes for observations:
* the base is our h=refs/heads/4.2-rc1 tree which includes merge of the
above mentioned tree (differences to linus/master are in ARM OMAP and
additional device drivers)
* this code compiles but IS COMPLETELY UNTESTED
* the device is called ?minibook?
* use letux_defconfig - because that is the name of our Linux distribution
(and in the long run should support different devices)
* the kernel still identifies itself as 4.1.0 - because Linus has not yet
officially released 4.2-rc1
* the device tree is automatically compiled into the uImage (by the Makefile
coming from upstream - so I have not changed the build system, just added a
minibook.dts)
My recent "bare metal" experiments failed to work whatsoever on the Letux, but
it was still happy booting a Linux 2.6 kernel from MMC, and I ran out of
patience trying to debug the "undebuggable". I later got some hints about
reset operations from someone with more knowledge about the JZ-series, but I
then got stuck trying to do something with the Ben NanoNote that also didn't
work out (related to interrupts and an initial error condition that I can't
manage to figure out, even though Linux must obviously be able to).
So any boot-level wisdom would be especially appreciated. As I noted earlier,
the U-Boot and Linux patches are quite horrible, and I still strive to find
the simplest recipe possible to boot these devices so that a more thorough
understanding can be attained.
* Daniel?s PM MCU driver does not compile (some structs have changed) and
needs to be fixed (therefore #CONFIG_POWER_MINIPC is not set)
* the device tree is prepared to add an &i2c node but I have not yet seen
any driver (not for jz4740, jz4780)
* there is no jz4730 specific code or DT config - everything is copied or
taken from jz4740 (which is likely wrong)
* things like gpios, keyboard scanner, lcd, usb, RAM/flash memory have to be
worked on
>From what I can see from the code that supposedly works on the jz4730, the LCD
initialisation is practically the same as for the jz4740. Various registers
are initialised and then the SoC assumes the job of continuously reading from
RAM and streaming the pixel data to the display. The difference between the
Letux and the NanoNote is that the latter uses a "narrower" connection and has
an SPI command link to the display.
A lot of the other things should be rather similar, but as I recall from my
previous (futile?) efforts, the locations of registers may be slightly
different, and it seemed at the time that some methods of access were
different, too. That might have been specific to the GPIO configuration
registers, however.
Comments, fixes, patches, ideas hints, criticism welcome :)
And if you want to test: beware! It may brick the device. And it probably
needs access to a serial console to see what is going on. I have to find
my Letux 400 with such interface first and check if it still works.
A long time ago it seemed like you might have found a way of unbricking these
devices, so it would be good news if you managed to rediscover some of that
wisdom. ;-)
Paul
------------------------------
_______________________________________________
Mipsbook-devel mailing list
Mipsbook-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
End of Mipsbook-devel Digest, Vol 34, Issue 8
*********************************************
