Le mercredi 18 mars 2015 à 10:24 +0200, Siarhei Siamashka a écrit : > On Sun, 15 Mar 2015 15:05:42 +0100 > Paul Kocialkowski <[email protected]> wrote: > > > Le dimanche 15 mars 2015 à 14:10 +0200, Siarhei Siamashka a écrit : > > > On Sun, 15 Mar 2015 12:12:00 +0100 > > > Paul Kocialkowski <[email protected]> wrote: > > > > > > > Le mardi 24 février 2015 à 11:58 +0200, Siarhei Siamashka a écrit : > > > > > On Sat, 21 Feb 2015 16:47:20 +0100 > > > > > Hans de Goede <[email protected]> wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > Newer u-boot versions may chose a different (better) PLL6 / PLL5 > > > > > > setting > > > > > > and/or different voltage settings. Unfortunately the old > > > > > > linux-sunxi-3.4 > > > > > > kernels have a number of hardcoded assumptions about PLL5 speed, > > > > > > and in some > > > > > > cases override the bootloader chosen PLL6 / voltages in a bad way. > > > > > > > > > > > > This patch series fixes this and is intended for the sunxi-3.4 > > > > > > branch. The > > > > > > first 2 patches are already in sunxi-3.4/staging, but they should > > > > > > really also > > > > > > be added to the sunxi-3.4 branch. The 2 new patches should be added > > > > > > to both. > > > > > > > > > > > > Note that sunxi-3.4/staging currently does not work for me (on > > > > > > sun5i at least) > > > > > > (*) so these patches have only been tested on the sunxi-3.4 branch. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Hans > > > > > > > > > > > > *) It does not boot at all for some reason, not a single message is > > > > > > printed > > > > > > on the serial console after u-boot has loaded the kernel. I'm > > > > > > afraid I do not > > > > > > have the time to investigate this. > > > > > > > > > > Thanks. I will allocate the next few days of my time on checking > > > > > what's > > > > > up with sunxi-3.4 and maybe we can make the final "graduation" release > > > > > for it. > > > > > > > > Any news on that front? > > > > > > Thanks for reminding. > > > > > > Well, the news is that I could not reproduce the alleged sun5i problem > > > with the stage/sunxi-3.4 branch on my A13-OLinuXino-Micro board. Which > > > obviously means that I can't debug it. > > > > Well, last time I checked, I didn't experience any particular problem > > with mainline U-Boot and sunxi-3.4 on sun5i/A13 but I probably lack > > context on this. > > There was just a report that the current sunxi-3.4 branch is "good" and > the stage/sunxi-3.4 is "bad" on sun5i hardware. But I could not confirm > this myself. > > Now we have a kind of "The Three Musketeers" scenario :-) Some users had > been "lost" along the way just because they have settled with some old > sunxi-3.4 release, which worked good enough for them. And these users > don't have any motivation for upgrading further. For example, this is > exactly what Olimex is doing with the 3.4 kernel: > > https://github.com/OLIMEX/OLINUXINO/tree/master/SOFTWARE/A20/A20-build > > Apparently they settled with 36080eb05e9a1e96d58e3168631d3cc9c612a0e3 > revision and also carry some extra patches of their own. > > Then Olimex discovered the interoperability problem with the mainline > u-boot (in a hard way, because the failure was non-obvious) and > complained in the mailing list. This thread is exactly a response > to the Olimex problem. However we have not heard from them back. And > this probably means that they just made their legacy snapshot work > correctly but could not care less about the fixes in the up to date > sunxi-3.4 and stage/sunxi-3.4 branches. > > Effectively, we have no real testers for the newest fixes. To add an > insult to injury, there is also a vague report about the problems on > sun5i hardware in the stage/sunxi-3.4 branch. Very nice, isn't it? > > Anyway, the patches are now in the "stage/sunxi-3.4" branch and the > relevant information is available in the linux-sunxi wiki: > > http://linux-sunxi.org/Mainline_U-boot#Troubleshooting > > This should cover all the use cases. And I think that the problem is > basically resolved now.
Thanks for pushing this. As I stated already, I didn't have much trouble with sun5i nor do I have any of the problems experienced by Olimex related to the PLLs rate (or maybe I do and didn't notice). Anyway, I understand that you're not in a comfortable situation regarding this and I understand the position of not investigating if the concerned people are not around nor willing to see the issues resolved. > > > Combined with Tsvetan's lack of any sign of response or any indications > > > that anyone else could be interested, I don't feel very much motivated > > > to do the "communication" part of the job, which is required to clarify > > > the status of these 3.4 branches and move them forward. > > > > Still, I would be interested in having a sunxi-3.4 branch that can > > actually be used on all the supported chips and devices. > > Well, the idea is that it already can be used on all the supported > chips and devices. > > And nobody needs to touch it anymore unless users report real problems. > There is simply no time to do this work. There is even no time to review > patches, which do not address important problems. I am starting to see that, I have submitted the same series for the third time a few days ago. I do not blame anyone for that, I know this is a community where about nobody has any obligation, but I would still like to see things move forward. > > > > I have been trying to boot sunxi-3.4 on sun7i/A20 using upstream U-Boot, > > > > with no success. I tried the current sunxi-3.4 branch and > > > > stage/sunxi-3.4, > > > > with and without these patches. > > > > > > > > It never prints anything on serial. > > > > > > Most likely you are missing the "setenv bootm_boot_mode sec" line in > > > your boot.cmd (otherwise the PSCI code in u-boot drops the CPU into > > > the non-secure mode and the sunxi-3.4 kernel can't handle it). > > > > That could be it, I'll investigate. > > Thanks. That was indeed my problem, thanks for reminding me of this. > > > The documentation in the wiki about the mainline u-boot is in a > > > pretty much bad shape, but at least this should be covered: > > > > > > http://linux-sunxi.org/Mainline_U-boot#Boot > > > > > > Alternatively, there is the old kernel compatibility mode in > > > u-boot, which can be selected in menuconfig. It should work > > > with any old sunxi-3.4 kernels. > > > > > > > On the other hand, I was able to boot mainline Linux (3.19) just fine. > > > > > > Right. That's what everyone should be using now. > > > > Well, it doesn't fit every use case yet and I will (sadly) have to use > > sunxi-3.4 for Replicant, so I need something that actually works. > > Would you maybe want to become the sunxi-3.4 branch maintainer? Because > realistically, you seem to be the only one here actually interested in > doing some 3.4 kernel work. Well, the situation for me is the following: I need a kernel that is fully-featured on tablets to have the best Replicant support possible. That is only possible with sunxi-3.4 since some key features are missing in mainline, such as audio, video decoding and a few more. If it was only a matter of small and easily written drivers such as touchscreen controllers or sensors, I would be very glad to do that work and use mainline instead of sunxi-3.4, but the reality is what it is and I don't think I will be able to use mainline with Replicant on Sunxi until a few years. Believe me when I say that I'm not happy to work on sunxi-3.4. Most of the Allwinner-specific code is crap, sometimes barely readable and most importantly, it has no future. I know that all the effort spent on it is somewhat wasted in the long run, but Replicant is a pragmatic solution for the short term, so that is what I'm going to use. So since I'm going to use sunxi-3.4, I have a roughly two possibilities: * commit all my changes to linux-sunxi/sunxi-3.4 and assume the responsibility of that repository * have a replicant sunxi-3.4 kernel, on which I make all the changes I need and send back patches that may interest others to sunxi-3.4 That last possibility is what I have been trying to do so far. There are a few reasons why I wouldn't want to become the maintainer of linux-sunxi/sunxi-3.4, mostly: * I don't have that much time available to work on free software projects due to studies that are very demanding and I'm already involved in many different projects (including being the lead developer of Replicant), so I'm afraid this will just shrink my free time even more * I am not *that* familiar with sunxi hardware and generally speaking, I'm far from being familiar with every aspect of embedded devices in general. Keep in mind that I'm a 19 year-old kid who didn't yet graduate from the university. Now if nobody is going to maintain linux-sunxi and I'm going to work on it, (read: cleaning the tree, defconfigs, merging the few patches I have standing by), I might as well get commit access and work on linux-sunxi/sunxi-3.4 instead of my own Replicant-centric repository. As for reviewing patches, I can always try and see. In any case, it won't be worse than having nobody to do it. > Also I think that I have already asked this before. Could you perhaps > create a wiki page with the Replicant requirements, just to see what is > still missing in the mainline kernel? People could use this list to > adjust their priorities when working on the mainline kernel code. I know I should start mentioning all that on the linux-sunxi wiki, but the truth is that I've made so little progress lately that I'm kind of ashamed to make any statement about it. Anyways, I'll keep that in mind and try to find the time to document it properly. As far as I know, the biggest show stopper is the lack of audio and video decoding driver, but there may be more. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: This is a digitally signed message part
