[Lenny400] Patches for linux-stable
H. Nikolaus Schaller
hns at goldelico.com
Sat Sep 2 13:51:32 CEST 2017
here is my result...
In a first step, I have split up your diff-patch into two.
A first one for introducing the jz4730 SoC and the other one
for introducing the mipsbook_400 (device tree).
Splitting SoC and device into two separate patch sets should
allow to develop things more in parallel and more easily
getting things upstream sometime in the future...
To that I have added the power management controller driver
by Daniel and some defconfig settings so it is now a total of
1. checkout letux-base (or e.g. v4.13-rc7)
2. merge/cherry-pick work/pboddie/mips/jz4730 work/hns/mipsbook400/dt work/hns/mipsbook400/pm work/hns/mips/defconfig
You can find the individual branches here:
Here is the merge result for easier access:
This compiles (at least the DTC succeeds for me) and I get a nice
-rw-r--r-- 1 hns staff 6639 2 Sep 11:42 arch/mips/boot/dts/ingenic/mipsbook_400.dtb
Now I hope that our diff+patch vs. git approaches do not conflict and we do not have
to redo this work each time :)
The ideal approach IMHO is to follow the linux-kernel style to work on patch sets, e.g. work/hns/mipsbook400/dt
and edit the history (not only piling up commits). There is always a warning that you never should do a
"git push --force origin branch" but there is an equivalent of "git reset --hard origin/branch" on the other end...
Otherwise mainline kernel development won't work.
Talking about mainline, Linus will publish most likely 4.13-rc8 on Monday (or even 4.13.0) and
I will then rebase and merge everything so that there is also a merged result available.
Well, it will need much more time than moving files around and editing patches until I can really
help testing and report a first boot-log. Initially I have to remove dust from my Letux 400 units
and find one which has the RS232 connector installed (or have to open the device and add the
connector). Then I have to learn again how to format a bootable SD card (or patch the makesd script)...
If you have patches for cherry-picking or squashing into the feature branches mentioned above, please
BR and thanks,
> Am 01.09.2017 um 23:35 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> Am 01.09.2017 um 23:20 schrieb Paul Boddie <paul at boddie.org.uk>:
>> On Friday 1. September 2017 22.55.54 H. Nikolaus Schaller wrote:
>>> I also took the time to add an untested draft for:
>>> * keyboard matrix
>>> * touch buttons
>> I guess this will eliminate some things from the board file that are currently
>> present as not-very-pretty arrays.
>>> * LEDs
>>> * i2c peripherals (rtc, power controller, audio codec)
>>> * sound
>>> * letux_defconfig to add drivers for matrix keyboard, rtc chip, wifi chip
>> Yes, particularly the latter is something I'm not tracking aggressively, which
>> means that I need to remember to enable things before claiming they compile.
>>> What may be very difficult is to get Ethernet working. The RTL8201CL
>>> is said to have no driver...
>> Maybe this is the "encoded" character driver David mentioned.
>>> What I think is missing in DT is:
>>> * LCD and backlight
>> I'm looking at that now. The LCD driver may only need minimal changes because
>> the SoCs are so similar. I will introduce some extra logic for testing for the
>> JZ4730 and eliminating some apparently unsupported functions (BPP > 16),
>>> * detecting AC and Battery charging
>>> * i2c and i2s drivers on SoC side
>>> * some pinmux
>>> * power control for WiFi on/off
>>> But I would say we have an untested and undebugged pile of ideas which
>>> already cover 70% of the device...
>>> finding what has changed is even simpler:
>>> git diff --names-only <from> <to>
>> Well, my excuse is that I don't navigate git manual pages very easily.
>> Probably because I'm usually thinking how much easier Mercurial is, I guess.
> git itself is fine - except the command line interface.
>>> Well, in this case it might be simple. My goal is to try to keep history as
>>> good as possible... This involves mixing git diff and blame and forming a
>>> series of new commits by git commit -C. It roughly works, but seems to
>>> loose some deletions and file renames. So if I merge things back it still
>> Especially things like renames, additions and removals are tricky to track
>> when capturing and presenting patches.
>>> Well, I have a different setup with a multi-architecture-cross-gcc-4.9.
>>> The ARM side works fine for years... Only the mips side comes up with such
>>> hickups. But more time will make it working :)
>> OK, I won't advise in this regard. Personally, though, I'm very happy with the
>> Debian cross-toolchains: they've been good for a couple of years, perhaps, and
>> I've deployed their code on the Ben NanoNote and PIC32MX without any problems.
> Well, I could use the GTA04 or Pyra to cross-compile (they run Debian), but
> up/downloading sources and results is a little time consuming since the bottleneck
> is the network. Doing everything locally is faster - but my machine does not
> have a Debian. Except in Virtual Box where importing/exporting sources and
> results is also not that nice.
> Anyways, I just need to invest some more time to locate the missing or wrong
> -I path. Maybe it is just referencing the ARM compiler and doesn't find MIPS
> specific headers...
> Lenny400 mailing list
> Lenny400 at goldelico.com
More information about the Lenny400