Hi Doug, On Sat, Jun 7, 2014 at 12:26 AM, Doug Anderson <dianders@xxxxxxxxxx> wrote: > Abhilash, > > On Fri, Jun 6, 2014 at 11:31 AM, Abhilash Kesavan > <kesavan.abhilash@xxxxxxxxx> wrote: >> Hi Doug, >> >> On Fri, Jun 6, 2014 at 11:50 PM, Doug Anderson <dianders@xxxxxxxxxx> wrote: >>> Abhilash, >>> >>> >>> >>> On Fri, Jun 6, 2014 at 11:12 AM, Abhilash Kesavan >>> <kesavan.abhilash@xxxxxxxxx> wrote: >>>> Hi Doug, >>>> >>>> On Fri, Jun 6, 2014 at 11:32 PM, Doug Anderson <dianders@xxxxxxxxxx> wrote: >>>>> Abhilash, >>>>> >>>>> On Fri, Jun 6, 2014 at 10:36 AM, Abhilash Kesavan >>>>> <kesavan.abhilash@xxxxxxxxx> wrote: >>>>>> Hi Doug, >>>>>> >>>>>> The first change in the kernel (clearing an iRAM location) is needed >>>>>> because of an unnecessary change that we are carrying in the Chrome >>>>>> U-boot. There is no reason for us to have the workaround in the >>>>>> mainline kernel. Rather, we should remove the check from our u-boot. >>>>>> However AFAIR a clean-up patch that I had posted internally was not >>>>>> accepted as we had frozen the SPL at the time. >>>>> >>>>> Ah, is that this one, or a different one? >>>>> >>>>> https://chromium-review.googlesource.com/#/c/66049/ >>>> Yes, this along with a kernel side change. >>> >>> Can we safely take this one without the kernel-side one? >> Yes, just the u-boot change should suffice. >>> >>> >>>>> If we land that patch now it won't help since nobody is going to be >>>>> updating their read-only firmware. We'll need to put code somewhere >>>>> that fixes it. >>>> We just carry the workaround fix locally until we migrate to mainline >>>> u-boot for 5420 where the unnecessay check will not be present. >>> >>> I think there are people out there who want to run a mainline kernel >>> on existing Chromebook 2 hardware and don't want to rewrite their RO >>> firmware. We need a solution for those people. >> Yes, I see your point. But, do you think someone who has changed the >> existing fused kernel on the device to a mainline one would be averse >> to applying a couple of small work-around changes as well ? Their >> finding this thread and the proposed "magic" fixes may be difficult >> but not the actual application I think. >> >> How about having a page similar to >> "http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/using-an-upstream-kernel-on-snow"; >> for Peach ? We could have the work-arounds listed there. > > We can (though the fewer weird things we have the better), but we > definitely need to provide workarounds that don't require people to > change their RO firmware. I do not quite agree with this. They do not need to change their RO firmware, just modify their boot commands. > > Thinking all that through, I think the answer is that we want to > abandon the U-Boot change above > <https://chromium-review.googlesource.com/#/c/66049/>. At this point > we're never going to take it at this point and there's no possible way > to do it in an RW firmware update (right?) since any workaround would > be overwritten by the SPL at resume time. Sure, will abandon. > > So the proper "fix" for the "mw.l 02073028 0" is a kernel fix. ...and I believe there is no "proper" fix for incorrect existing code in non-mainline u-boot. > if upstream doesn't want land it because it's impure then we'll just > have to list it on our "apply these hacks to your kernel". You sent > me this as a kernel fix before and now I think I understand why (to > handle the s2r case). Can you please post this up to the mailing > list? Please make sure it will handle the suspend/resume case > whenever suspend/resume starts working (I haven't tested but I > remember hearing that it doesn't work). Are you talking about the re-writing the mcpm entry point address post-resume ? > > Note: I think there are actually two possible kernel fixes (right?): > 1. Have the kernel itself (re)write the code at 0x02073000 at bootup / > resume time. I don't know of any reason why this should need to be in > U-Boot. Maybe upstream would take this? > > 2. Have the kernel clear this flag to work with existing Chromebook 2 firmware. > > -- > > The proper "fix" for the "mw.l 10d25000 3" is a U-Boot fix. Let me > see if I can put together something that will handle this in RW > U-Boot. Even if we don't officially ship this RW U-Boot we can always > point people at the binaries. > > > Does that make sense? > > -Doug -- 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
 |