[Letux-kernel] JZ4730 kernel support

[H. Nikolaus Schaller]

> Am 21.10.2019 um 13:10 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
>> 
>> Am 21.10.2019 um 13:01 schrieb Paul Boddie <paul at boddie.org.uk>:
>> 
>> On Monday 21. October 2019 09.37.32 H. Nikolaus Schaller wrote:
>>>> Am 19.10.2019 um 13:50 schrieb Paul Boddie <paul at boddie.org.uk>:
>>>> 
>>>> commit 48beba8932f2d296cd0a031003cf295096c9dc40 (grafted,
>>>> origin/letux/jz4730)
>>> Yes, that did work.
>> 
>> Great!
>> 
>>>> There should be five patches in this bundle, three of which you will have
>>>> seen before. Sorry not to be able to prepare these in a nicer way, but
>>>> git generally isn't happy running properly on my hardware with these
>>>> repositories.
>>> No problem. A patch set sent like this just needs knowledge about the
>>> merge base - if the merge base itself changes. This seems to be the cas
>>> with -rc for the ingenic subtree...
>> 
>> Is the history being rewritten or something?
> 
> Yes. All letux/ branches are rebased regularly on top of the latest
> linus/master version.
> 
> This makes sure that (after long time) commits posted from a branch
> to the LKML are "eaten up" from the bottom when they are merged by
> Linus. And if all such commits are in linus/master the feature branch
> becomes empty.
> 
> And in the mean-time we have a working system with latest upstream
> changes.
> 
>> That is the only explanation for 
>> why patches might suddenly not be applicable, at least if I am making them for 
>> the right branch.
>> 
>>>> Maybe preparing them all separately instead of in combined form is better.
>>>> I've attached an archive to this message containing the individual
>>>> patches.
>>> 
>>> That doesn't make a big difference - except that some patches may apply
>>> cleanly while others still fail.
>> 
>> Yes, the intention is to permit partial failure rather than always experience 
>> complete failure.
>> 
>>> But what is your git repo problem? I have not seen a problem cloning it on
>>> quite different systems: e.g. macOS or a RasPi 3B+ with a 200GB µSD card
>>> running ifself with LetuxOS.
>> 
>> I did look at my complaints about this in the archives, but I don't think 
>> there was a successful resolution. You did write something about this, but I 
>> didn't find that message.
>> 
>> It is possible that some tuning is needed with git, given that I am using 
>> machines with only 1GB RAM,
> 
> Well, the RasPi 3 also has only 1GB. Yes, it is slow but seems to work.

Before someone asks: I also tried to build the kernel.
Yes, it works (all without swap). But takes quite some time.

I have found notes about what I did:

Result of

	git checkout letux-5.4-rc2
	make clean
	time make -j4 V=2 letux_defconfig LOADADDR=0x80008000 uImage modules

is

	real	75m23.320s
	user	265m20.735s
	sys	14m54.492s

> 
>> but as I noted before, the advice about such 
>> things is all over the place: people suggest changing some settings, other 
>> people claimed that it worked for them, still other people claim that it 
>> didn't work but something else did. And so on.
>> 
>>> And maybe it would be good if you would become "Happy Crew" member of the
>>> letux kernel team and get write-access to the repo:
>>> 
>>> http://projects.goldelico.com/p/gta04-kernel/
>>> 
>>> I have already added you. To get ssh write access you should add your
>>> key to the user-config page and then I have to run a script to copy it
>>> to the ssh/git daemon's permission files.
>> 
>> I did manage to submit patches to the gta04-kernel before now. Navigating 
>> branches was slow, but it did work, more or less.
>> 
>> My workaround currently involves a shallow clone of the appropriate branch in 
>> the letux-kernel repository, which is the one piece of advice I found that 
>> actually seems to work for people in my situation. Unfortunately, switching 
>> branches seems to cause git to want to fetch all the history, even though the 
>> (awful) man pages suggest that this shouldn't happen for shallow clones. And 
>> it is this history fetching that leads to the "index pack failed" error.
> 
> Hm. Do you use git or http access? AFAIR git access is not really reliable.
> https or ssh+git can retry in some cases.
> 
> Or can you do a test if it is really on your side:
> 
> git clone git at github.com:goldelico/letux-kernel.git
> 
> If that works it is more a network issue (which may lead to a timeout somewhere).
> 
>> I'll try and think of other approaches, but I don't have so many ideas at the 
>> moment. Then again, I don't think there are so many other changes to be made 
>> at the moment, either.
> 
> Ok, fine.
> 
> BR and thanks,
> Nikolaus
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel