Message ID | 1426783559-26610-17-git-send-email-yorksun@freescale.com |
---|---|
State | Superseded |
Delegated to: | York Sun |
Headers | show |
On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: > From: Scott Wood <scottwood@freescale.com> > > This lets us see the problems (close to) when they happen, > rather than Linux hanging when it enables them prior to having a > working console. FYI, if the Linux driver for your UART supports earlycon, that should work since commit 7a9c43bed891d1f8 ("setup: Move unmask of async interrupts after possible earlycon setup"). I hope that SError is masked again prior to entering Linux, as required by the boot protocol? Mark. > Signed-off-by: Scott Wood <scottwood@freescale.com> > --- > arch/arm/cpu/armv8/fsl-lsch3/cpu.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c > index 07064a3..22b5fb2 100644 > --- a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c > +++ b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c > @@ -263,6 +263,10 @@ int arch_cpu_init(void) > __asm_invalidate_tlb_all(); > early_mmu_setup(); > set_sctlr(get_sctlr() | CR_C); > + > + /* Enable system error aborts */ > + asm volatile("msr daifclr, #4" : : : "memory"); > + > return 0; > } > > -- > 1.7.9.5 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >
On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: > On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: > > From: Scott Wood <scottwood@freescale.com> > > > > This lets us see the problems (close to) when they happen, > > rather than Linux hanging when it enables them prior to having a > > working console. > > FYI, if the Linux driver for your UART supports earlycon, that should > work since commit 7a9c43bed891d1f8 ("setup: Move unmask of async > interrupts after possible earlycon setup"). I wrote this patch in the context of board bringup, where I was stuck using an older kernel. In any case, when U-Boot causes a problem we want to see it in U-Boot. > I hope that SError is masked again prior to entering Linux, as required > by the boot protocol? Doesn't look like it based on grepping for daifset. Where is the boot protocol documented? Just for future reference -- I agree that leaving this enabled during the handover would be a bad thing. > Mark. > > > Signed-off-by: Scott Wood <scottwood@freescale.com> York, where's your signoff since you're the one submitting the patch? -Scott
On 03/19/2015 12:52 PM, Scott Wood wrote: > On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: >> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: >>> From: Scott Wood <scottwood@freescale.com> >>> >>> This lets us see the problems (close to) when they happen, >>> rather than Linux hanging when it enables them prior to having a >>> working console. >> >> FYI, if the Linux driver for your UART supports earlycon, that should >> work since commit 7a9c43bed891d1f8 ("setup: Move unmask of async >> interrupts after possible earlycon setup"). > > I wrote this patch in the context of board bringup, where I was stuck > using an older kernel. In any case, when U-Boot causes a problem we > want to see it in U-Boot. > >> I hope that SError is masked again prior to entering Linux, as required >> by the boot protocol? > > Doesn't look like it based on grepping for daifset. > > Where is the boot protocol documented? Just for future reference -- I > agree that leaving this enabled during the handover would be a bad > thing. > >> Mark. >> >>> Signed-off-by: Scott Wood <scottwood@freescale.com> > > York, where's your signoff since you're the one submitting the patch? I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by. York
On Thu, 2015-03-19 at 12:54 -0700, York Sun wrote: > > On 03/19/2015 12:52 PM, Scott Wood wrote: > > On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: > >> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: > >>> Signed-off-by: Scott Wood <scottwood@freescale.com> > > > > York, where's your signoff since you're the one submitting the patch? > > I am sending many patches in this set. Since I didn't contribute to this patch, > I didn't add my signed-off-by. That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well? -Scott
On 03/19/2015 12:58 PM, Scott Wood wrote: > On Thu, 2015-03-19 at 12:54 -0700, York Sun wrote: >> >> On 03/19/2015 12:52 PM, Scott Wood wrote: >>> On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: >>>> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: >>>>> Signed-off-by: Scott Wood <scottwood@freescale.com> >>> >>> York, where's your signoff since you're the one submitting the patch? >> >> I am sending many patches in this set. Since I didn't contribute to this patch, >> I didn't add my signed-off-by. > > That's not what signed-off-by means. I realize (though never understood > why) the U-Boot project differs from Linux rules in terms of whether > custodians are expected to sign off patches when applying, but does that > extend to submitting patches by e-mail as well? > I don't have the answer myself. I haven't added any of my signed-off-by for the patches I squashed/tested/sent. For small patch set, I would request the original author to send each patch. For large set with dependency, I send patch on behalf of the authors. I don't want to take credit for the patch I didn't contribute the change. I test all of them though. If the signed-off-by has different meanings, I am OK to change my practice. York
On Thu, 2015-03-19 at 13:02 -0700, York Sun wrote: > > On 03/19/2015 12:58 PM, Scott Wood wrote: > > On Thu, 2015-03-19 at 12:54 -0700, York Sun wrote: > >> > >> On 03/19/2015 12:52 PM, Scott Wood wrote: > >>> On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: > >>>> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: > >>>>> Signed-off-by: Scott Wood <scottwood@freescale.com> > >>> > >>> York, where's your signoff since you're the one submitting the patch? > >> > >> I am sending many patches in this set. Since I didn't contribute to this patch, > >> I didn't add my signed-off-by. > > > > That's not what signed-off-by means. I realize (though never understood > > why) the U-Boot project differs from Linux rules in terms of whether > > custodians are expected to sign off patches when applying, but does that > > extend to submitting patches by e-mail as well? > > > > I don't have the answer myself. I haven't added any of my signed-off-by for the > patches I squashed/tested/sent. For small patch set, I would request the > original author to send each patch. For large set with dependency, I send patch > on behalf of the authors. I don't want to take credit for the patch I didn't > contribute the change. I test all of them though. The From: line is for giving credit. Signed-off-by shows the path the patch took. Plus, leaving your name off puts all the blame on the author, when they weren't the ones who decided the patch was ready to submit. :-) -Scott
On 03/19/2015 01:06 PM, Scott Wood wrote: > On Thu, 2015-03-19 at 13:02 -0700, York Sun wrote: >> >> On 03/19/2015 12:58 PM, Scott Wood wrote: >>> On Thu, 2015-03-19 at 12:54 -0700, York Sun wrote: >>>> >>>> On 03/19/2015 12:52 PM, Scott Wood wrote: >>>>> On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: >>>>>> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: >>>>>>> Signed-off-by: Scott Wood <scottwood@freescale.com> >>>>> >>>>> York, where's your signoff since you're the one submitting the patch? >>>> >>>> I am sending many patches in this set. Since I didn't contribute to this patch, >>>> I didn't add my signed-off-by. >>> >>> That's not what signed-off-by means. I realize (though never understood >>> why) the U-Boot project differs from Linux rules in terms of whether >>> custodians are expected to sign off patches when applying, but does that >>> extend to submitting patches by e-mail as well? >>> >> >> I don't have the answer myself. I haven't added any of my signed-off-by for the >> patches I squashed/tested/sent. For small patch set, I would request the >> original author to send each patch. For large set with dependency, I send patch >> on behalf of the authors. I don't want to take credit for the patch I didn't >> contribute the change. I test all of them though. > > The From: line is for giving credit. Signed-off-by shows the path the > patch took. Plus, leaving your name off puts all the blame on the > author, when they weren't the ones who decided the patch was ready to > submit. :-) > When multiple patches are squashed, I put authors' name in signed-off-by. For this reason, I think adding my signoff will be confusing. But I agree with you that I should have my name somewhere for the patches I sent. Doesn't the email "from" qualify? York
On Thu, 2015-03-19 at 13:27 -0700, York Sun wrote: > > On 03/19/2015 01:06 PM, Scott Wood wrote: > > On Thu, 2015-03-19 at 13:02 -0700, York Sun wrote: > >> > >> On 03/19/2015 12:58 PM, Scott Wood wrote: > >>> On Thu, 2015-03-19 at 12:54 -0700, York Sun wrote: > >>>> > >>>> On 03/19/2015 12:52 PM, Scott Wood wrote: > >>>>> On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: > >>>>>> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: > >>>>>>> Signed-off-by: Scott Wood <scottwood@freescale.com> > >>>>> > >>>>> York, where's your signoff since you're the one submitting the patch? > >>>> > >>>> I am sending many patches in this set. Since I didn't contribute to this patch, > >>>> I didn't add my signed-off-by. > >>> > >>> That's not what signed-off-by means. I realize (though never understood > >>> why) the U-Boot project differs from Linux rules in terms of whether > >>> custodians are expected to sign off patches when applying, but does that > >>> extend to submitting patches by e-mail as well? > >>> > >> > >> I don't have the answer myself. I haven't added any of my signed-off-by for the > >> patches I squashed/tested/sent. For small patch set, I would request the > >> original author to send each patch. For large set with dependency, I send patch > >> on behalf of the authors. I don't want to take credit for the patch I didn't > >> contribute the change. I test all of them though. > > > > The From: line is for giving credit. Signed-off-by shows the path the > > patch took. Plus, leaving your name off puts all the blame on the > > author, when they weren't the ones who decided the patch was ready to > > submit. :-) > > > > When multiple patches are squashed, I put authors' name in signed-off-by. For > this reason, I think adding my signoff will be confusing. If there are multiple authors you can give credit with an explicit statement in the changelog. > But I agree with you that I should have my name somewhere for the patches I > sent. Doesn't the email "from" qualify? The email "from" doesn't go in the git history. -Scott
On 03/19/2015 01:37 PM, Scott Wood wrote: > On Thu, 2015-03-19 at 13:27 -0700, York Sun wrote: >> >> On 03/19/2015 01:06 PM, Scott Wood wrote: >>> On Thu, 2015-03-19 at 13:02 -0700, York Sun wrote: >>>> >>>> On 03/19/2015 12:58 PM, Scott Wood wrote: >>>>> On Thu, 2015-03-19 at 12:54 -0700, York Sun wrote: >>>>>> >>>>>> On 03/19/2015 12:52 PM, Scott Wood wrote: >>>>>>> On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: >>>>>>>> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: >>>>>>>>> Signed-off-by: Scott Wood <scottwood@freescale.com> >>>>>>> >>>>>>> York, where's your signoff since you're the one submitting the patch? >>>>>> >>>>>> I am sending many patches in this set. Since I didn't contribute to this patch, >>>>>> I didn't add my signed-off-by. >>>>> >>>>> That's not what signed-off-by means. I realize (though never understood >>>>> why) the U-Boot project differs from Linux rules in terms of whether >>>>> custodians are expected to sign off patches when applying, but does that >>>>> extend to submitting patches by e-mail as well? >>>>> >>>> >>>> I don't have the answer myself. I haven't added any of my signed-off-by for the >>>> patches I squashed/tested/sent. For small patch set, I would request the >>>> original author to send each patch. For large set with dependency, I send patch >>>> on behalf of the authors. I don't want to take credit for the patch I didn't >>>> contribute the change. I test all of them though. >>> >>> The From: line is for giving credit. Signed-off-by shows the path the >>> patch took. Plus, leaving your name off puts all the blame on the >>> author, when they weren't the ones who decided the patch was ready to >>> submit. :-) >>> >> >> When multiple patches are squashed, I put authors' name in signed-off-by. For >> this reason, I think adding my signoff will be confusing. > > If there are multiple authors you can give credit with an explicit > statement in the changelog. > >> But I agree with you that I should have my name somewhere for the patches I >> sent. Doesn't the email "from" qualify? > > The email "from" doesn't go in the git history. Changelog doesn't goes to git history either. Anyway, adding my signed-off-by is not a burden to me. York
On Thu, 2015-03-19 at 13:47 -0700, York Sun wrote: > > On 03/19/2015 01:37 PM, Scott Wood wrote: > > On Thu, 2015-03-19 at 13:27 -0700, York Sun wrote: > >> > >> On 03/19/2015 01:06 PM, Scott Wood wrote: > >>> On Thu, 2015-03-19 at 13:02 -0700, York Sun wrote: > >>>> > >>>> On 03/19/2015 12:58 PM, Scott Wood wrote: > >>>>> On Thu, 2015-03-19 at 12:54 -0700, York Sun wrote: > >>>>>> > >>>>>> On 03/19/2015 12:52 PM, Scott Wood wrote: > >>>>>>> On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: > >>>>>>>> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: > >>>>>>>>> Signed-off-by: Scott Wood <scottwood@freescale.com> > >>>>>>> > >>>>>>> York, where's your signoff since you're the one submitting the patch? > >>>>>> > >>>>>> I am sending many patches in this set. Since I didn't contribute to this patch, > >>>>>> I didn't add my signed-off-by. > >>>>> > >>>>> That's not what signed-off-by means. I realize (though never understood > >>>>> why) the U-Boot project differs from Linux rules in terms of whether > >>>>> custodians are expected to sign off patches when applying, but does that > >>>>> extend to submitting patches by e-mail as well? > >>>>> > >>>> > >>>> I don't have the answer myself. I haven't added any of my signed-off-by for the > >>>> patches I squashed/tested/sent. For small patch set, I would request the > >>>> original author to send each patch. For large set with dependency, I send patch > >>>> on behalf of the authors. I don't want to take credit for the patch I didn't > >>>> contribute the change. I test all of them though. > >>> > >>> The From: line is for giving credit. Signed-off-by shows the path the > >>> patch took. Plus, leaving your name off puts all the blame on the > >>> author, when they weren't the ones who decided the patch was ready to > >>> submit. :-) > >>> > >> > >> When multiple patches are squashed, I put authors' name in signed-off-by. For > >> this reason, I think adding my signoff will be confusing. > > > > If there are multiple authors you can give credit with an explicit > > statement in the changelog. > > > >> But I agree with you that I should have my name somewhere for the patches I > >> sent. Doesn't the email "from" qualify? > > > > The email "from" doesn't go in the git history. > > Changelog doesn't goes to git history either. Yes, it does. I'm not talking about the comments below the --- that are sometimes used to give history of the patch itself or other transient info. The stuff above the --- is the git changelog. -Scott
On 03/19/2015 01:51 PM, Scott Wood wrote: > On Thu, 2015-03-19 at 13:47 -0700, York Sun wrote: >> >> On 03/19/2015 01:37 PM, Scott Wood wrote: >>> On Thu, 2015-03-19 at 13:27 -0700, York Sun wrote: >>>> >>>> On 03/19/2015 01:06 PM, Scott Wood wrote: >>>>> On Thu, 2015-03-19 at 13:02 -0700, York Sun wrote: >>>>>> >>>>>> On 03/19/2015 12:58 PM, Scott Wood wrote: >>>>>>> On Thu, 2015-03-19 at 12:54 -0700, York Sun wrote: >>>>>>>> >>>>>>>> On 03/19/2015 12:52 PM, Scott Wood wrote: >>>>>>>>> On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: >>>>>>>>>> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: >>>>>>>>>>> Signed-off-by: Scott Wood <scottwood@freescale.com> >>>>>>>>> >>>>>>>>> York, where's your signoff since you're the one submitting the patch? >>>>>>>> >>>>>>>> I am sending many patches in this set. Since I didn't contribute to this patch, >>>>>>>> I didn't add my signed-off-by. >>>>>>> >>>>>>> That's not what signed-off-by means. I realize (though never understood >>>>>>> why) the U-Boot project differs from Linux rules in terms of whether >>>>>>> custodians are expected to sign off patches when applying, but does that >>>>>>> extend to submitting patches by e-mail as well? >>>>>>> >>>>>> >>>>>> I don't have the answer myself. I haven't added any of my signed-off-by for the >>>>>> patches I squashed/tested/sent. For small patch set, I would request the >>>>>> original author to send each patch. For large set with dependency, I send patch >>>>>> on behalf of the authors. I don't want to take credit for the patch I didn't >>>>>> contribute the change. I test all of them though. >>>>> >>>>> The From: line is for giving credit. Signed-off-by shows the path the >>>>> patch took. Plus, leaving your name off puts all the blame on the >>>>> author, when they weren't the ones who decided the patch was ready to >>>>> submit. :-) >>>>> >>>> >>>> When multiple patches are squashed, I put authors' name in signed-off-by. For >>>> this reason, I think adding my signoff will be confusing. >>> >>> If there are multiple authors you can give credit with an explicit >>> statement in the changelog. >>> >>>> But I agree with you that I should have my name somewhere for the patches I >>>> sent. Doesn't the email "from" qualify? >>> >>> The email "from" doesn't go in the git history. >> >> Changelog doesn't goes to git history either. > > Yes, it does. I'm not talking about the comments below the --- that are > sometimes used to give history of the patch itself or other transient > info. The stuff above the --- is the git changelog. > Can you show me some examples so I can follow? Back to this patch, it is not critical for u-boot to operate. Do you want to drop this patch? York
On Thu, 2015-03-19 at 13:56 -0700, York Sun wrote: > > On 03/19/2015 01:51 PM, Scott Wood wrote: > > On Thu, 2015-03-19 at 13:47 -0700, York Sun wrote: > >> > >> On 03/19/2015 01:37 PM, Scott Wood wrote: > >>> On Thu, 2015-03-19 at 13:27 -0700, York Sun wrote: > >>>> > >>>> On 03/19/2015 01:06 PM, Scott Wood wrote: > >>>>> On Thu, 2015-03-19 at 13:02 -0700, York Sun wrote: > >>>>>> > >>>>>> On 03/19/2015 12:58 PM, Scott Wood wrote: > >>>>>>> On Thu, 2015-03-19 at 12:54 -0700, York Sun wrote: > >>>>>>>> > >>>>>>>> On 03/19/2015 12:52 PM, Scott Wood wrote: > >>>>>>>>> On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: > >>>>>>>>>> On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: > >>>>>>>>>>> Signed-off-by: Scott Wood <scottwood@freescale.com> > >>>>>>>>> > >>>>>>>>> York, where's your signoff since you're the one submitting the patch? > >>>>>>>> > >>>>>>>> I am sending many patches in this set. Since I didn't contribute to this patch, > >>>>>>>> I didn't add my signed-off-by. > >>>>>>> > >>>>>>> That's not what signed-off-by means. I realize (though never understood > >>>>>>> why) the U-Boot project differs from Linux rules in terms of whether > >>>>>>> custodians are expected to sign off patches when applying, but does that > >>>>>>> extend to submitting patches by e-mail as well? > >>>>>>> > >>>>>> > >>>>>> I don't have the answer myself. I haven't added any of my signed-off-by for the > >>>>>> patches I squashed/tested/sent. For small patch set, I would request the > >>>>>> original author to send each patch. For large set with dependency, I send patch > >>>>>> on behalf of the authors. I don't want to take credit for the patch I didn't > >>>>>> contribute the change. I test all of them though. > >>>>> > >>>>> The From: line is for giving credit. Signed-off-by shows the path the > >>>>> patch took. Plus, leaving your name off puts all the blame on the > >>>>> author, when they weren't the ones who decided the patch was ready to > >>>>> submit. :-) > >>>>> > >>>> > >>>> When multiple patches are squashed, I put authors' name in signed-off-by. For > >>>> this reason, I think adding my signoff will be confusing. > >>> > >>> If there are multiple authors you can give credit with an explicit > >>> statement in the changelog. > >>> > >>>> But I agree with you that I should have my name somewhere for the patches I > >>>> sent. Doesn't the email "from" qualify? > >>> > >>> The email "from" doesn't go in the git history. > >> > >> Changelog doesn't goes to git history either. > > > > Yes, it does. I'm not talking about the comments below the --- that are > > sometimes used to give history of the patch itself or other transient > > info. The stuff above the --- is the git changelog. > > > > Can you show me some examples so I can follow? "This patch includes work by <name>, <name>, and <name>." > Back to this patch, it is not critical for u-boot to operate. Do you want to > drop this patch? From this patchset, sure. But it ought to be fixed and resubmitted at some point. -Scott
On Thu, Mar 19, 2015 at 07:52:30PM +0000, Scott Wood wrote: > On Thu, 2015-03-19 at 18:14 +0000, Mark Rutland wrote: > > On Thu, Mar 19, 2015 at 04:45:48PM +0000, York Sun wrote: > > > From: Scott Wood <scottwood@freescale.com> > > > > > > This lets us see the problems (close to) when they happen, > > > rather than Linux hanging when it enables them prior to having a > > > working console. > > > > FYI, if the Linux driver for your UART supports earlycon, that should > > work since commit 7a9c43bed891d1f8 ("setup: Move unmask of async > > interrupts after possible earlycon setup"). > > I wrote this patch in the context of board bringup, where I was stuck > using an older kernel. In any case, when U-Boot causes a problem we > want to see it in U-Boot. Sure. The Linux patch helps when Linux triggers an SError after taking ownership of the vectors. > > I hope that SError is masked again prior to entering Linux, as required > > by the boot protocol? > > Doesn't look like it based on grepping for daifset. Ok. That should happen before you call the kernel. Otherwise if the kernel triggers an SError between setting up the vectors and discovering the UART, you won't get any output. Linux requires that all the DAIF exceptions are masked prior to entry. > Where is the boot protocol documented? Just for future reference -- I > agree that leaving this enabled during the handover would be a bad > thing. In the Linux kernel tree see Documentation/arm64/booting.txt [1]. This is periodically updated with clarifications and updates for new architectural features, though it should always remain compatible. Mark. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c index 07064a3..22b5fb2 100644 --- a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c +++ b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c @@ -263,6 +263,10 @@ int arch_cpu_init(void) __asm_invalidate_tlb_all(); early_mmu_setup(); set_sctlr(get_sctlr() | CR_C); + + /* Enable system error aborts */ + asm volatile("msr daifclr, #4" : : : "memory"); + return 0; }