Kevin, As I wrote you previously outside the list this is the commit "ARM: EXYNOS: SWRESET is needed to boot secondary CPU on exynos3250" that I was expecting it to fix XU3 as well and apparently it is.. Next week if everything goes as I plan I'll check if I can use the same code to enable the A7's on XU3 as well. If its possible to use the same code I'll try to upstream this next week. It would be nice if Samsung could tell what in our u-boot (provided by LSI) is needed to be changed as I can just push any changes to our u-boot. BR, Mauro On Fri, Oct 24, 2014 at 2:00 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: > Abhilash Kesavan <kesavan.abhilash@xxxxxxxxx> writes: > >> On Thu, Oct 23, 2014 at 9:26 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >>> Abhilash Kesavan <a.kesavan@xxxxxxxxxxx> writes: >>> >>>> The change was based on my reading of the platsmp file of the >>>> Odroid-xu3 3.10 kernel and issues experienced previously. From what I >>>> understand, the platsmp code in 3.10 kernel is trying to reset the A7s >>>> and my change just bypasses the check (no magic here ). The change was >>>> only suggested as a workaround to get 8 cores up using MCPM and not an >>>> actual fix. I had explained this in my mail to Kevin. So, if this >>>> were to be mainlined we would probably need to use something like >>>> exynos_core_restart in mcpm along with the workaround. But, this is >>>> all guesswork on my part and someone with knowledge of the 3.10 >>>> kernel/bootloader needs to comment. >>> >>> Unfortunately, the harkernel tree git repo doesn't help understand where >>> the change came from because an entire v3.10.y based Samsung BSP is >>> checked into the tree on top of a v3.8.y kernel in a single commit !!! >>> >>> Abhilash, in the absence of the original author, could write up a patch >>> with your change? >>> >>> Or, if you can help me with a detailed changelog, I can work on the patch. >>> I don't have any exynos docs, so it would be good to have a description >>> of what reading/writing to that register are actually doing. >> >> I could post a patch with an explanation of how I think the workaround >> works, but there are a few issues: >> - I am not completely confident that this is the best/right change. > > Maybe post as RFC. > >> - We are adding code to the exynos mcpm back-end to work-around a >> bootloader setting for Odroid-xu3. We would have to make it specific >> to odroid somehow as we do not require it for 5420/5800 chromebooks. > > Hmm, if you have an idea how/where to fix it in u-boot, I'd be glad to > give that a try. I'm using the hardkernel u-boot repo: > https://github.com/hardkernel/u-boot.git, branch odroidxu3-v2012.07, and > would be happy to test any fixes there. > >> - This might solve the 8 core boot-up issue but other scenarios might >> still fail like the one Joonyoung has already reported. > > I replied yesterday to that report, and the one Joonyoung reported > exists with or without your proposed fix, so I don't think they're > directly related. > >>> >>> Also, can you explain what you meant by using exynos_core_restart? I >>> don't see that function in mainline. >> >> It is present in linux-next and kgene's for-next branch as part of >> this commit "ARM: EXYNOS: SWRESET is needed to boot secondary CPU on >> exynos3250". > > OK, I see it now. > > Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |