[Lenny400] More patches for linux-stable

Paul Boddie paul at boddie.org.uk
Thu Sep 7 12:54:58 CEST 2017

On Thursday 7. September 2017 07.48.42 H. Nikolaus Schaller wrote:
> Hi Paul,
> we now have a state where we can put the letux-kernel mailing list in CC.
> Maybe it helps the others doing ARM work or they can comment for MIPS as
> well.

I guess I'll have to subscribe to that list or my messages might cause 
moderation requests.

> > Am 05.09.2017 um 17:58 schrieb Paul Boddie <paul at boddie.org.uk>:
> > 
> > The latter is the result of manually taking my changes and adding them to
> > the mipsbook_400.dts file, since the minipc.dts file wasn't around in
> > the repository, so there was no continuity.
> Well, here I had applied a git tree-filter to do a fresh start with
> mipsbook_400.dts :) But if we continue from here on, it should not appear
> again.


> > I also couldn't find the board-
> > minipc.c file in either branch, and so those changes are not provided,
> > but I imagine that the aim is to eliminate this file, anyway.
> Maybe I forgot to include it? Usually a DTB should completely describe a
> board. Or stuff from board-minipc.c should go into proper drivers.

It is on the work/pboddie/mips/jz4730 branch, I think, so maybe I was 
confused. But this meant that transferring functionality between the board 
file and the Minibook device tree file involved things disappearing from one 
branch and maybe reappearing on the other. Which is how things tend to get 
lost. ;-)

> I have looked into your first big patch and it indeed contains only
> information that should be replaced by DT, so we do not need it in full-DT
> mode.
> Maybe we should review if we did not forget anything. For example the

The latter will be specified in the mmc device node, but the former certainly 
needs to be remembered somehow.

> > Although I tried to make sense of the pinctrl stuff, it isn't clear to me
> > how the "function" maps to the actual alternate/alternative function
> > setting on the pins.
> I have looked into it a little and it differs how OMAP/ARM is doing pinmux.
> Something for more detailed study...

I'll have to ask around, I think.


> This time it applied almost fine on first attempt. I just had to insert it
> before my i2c + i2s placeholder patch (so that the mipsbook_400.dts can
> reference &i2c) and fix a minor merge conflict.
> So this seems to be the final area to work on...

I'll try and re-formulate the second set of changes against these new heads. 
These were included in the combined patch I sent yesterday.


> Well, I did try to clone on the Letux Cortex 8 (512 MB RAM, 64 GB µSD):
> First attempt:
> root at letux:~# git clone git://git.goldelico.com/gta04-kernel.git
> Cloning into 'gta04-kernel'...
> remote: Zähle Objekte: 6753575, Fertig.
> remote: Komprimiere Objekte: 100% (978066/978066), Fertig.
> error: index-pack died of signal 9753575), 1.09 GiB | 268.00 KiB/s
> fatal: index-pack failed
> root at letux:~#
> After enabling 4GB Swap Space:
> root at letux:~# git clone git://git.goldelico.com/gta04-kernel.git
> Cloning into 'gta04-kernel'...
> remote: Zähle Objekte: 6753575, Fertig.
> remote: Komprimiere Objekte: 100% (978066/978066), Fertig.
> Receiving objects: 100% (6753575/6753575), 1.41 GiB | 679.00 KiB/s, done.
> remote: Total 6753575 (delta 5729785), reused 6750590 (delta 5727119)
> Resolving deltas: 100% (5729785/5729785), done.
> Checking connectivity... done.
> Checking out files: 100% (60075/60075), done.
> root at letux:~#
> It took very long time (the full day...) for the "Resolving deltas" step.
> So the issue is that the repository is big and needs enough RAM/Swap
> on the client side. Nothing that can be solved on the server side
> (maybe except by pruning some history).

Yes, I guess git doesn't handle memory limitations gracefully. Still, I don't 
have any significant problems at the moment, so this probably isn't something 
to worry about.

> Regarding real tests the Picoblade connectors for UART should arrive
> tomorrow and I just have to find one more of my units (I had a sample
> with red plastics case). Then I can check which ones are still working,
> which need repair or a RS232 socket.

Well, I hope these efforts help to rejuvenate them in some way.


More information about the Lenny400 mailing list