[Letux-kernel] JZ4730 kernel support
H. Nikolaus Schaller
hns at goldelico.com
Mon Oct 21 13:17:50 CEST 2019
> 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,
>>> Yes, that did work.
>>>> 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
>>> 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
>> 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
>>> 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:
git checkout letux-5.4-rc2
time make -j4 V=2 letux_defconfig LOADADDR=0x80008000 uImage modules
>> 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:
>>> 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,
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
More information about the Letux-kernel