- TF-A - lists.trustedfirmware.org

Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by Raghu K

Nice debug! Apart from the issue you pointed out, there is also the issue with not checking the return code. The ras handler should really be checking or panic'ing if there is an unexpected error code from spm_sp_call and sdei_dispatch_event. -Raghu On 4/20/20 2:37 PM, Olivier Deprez via TF-A wrote: > Hi Bin Wu, > > Here's an early observation. On receiving the RAS fiq interrupt the following occurs: > > ehf_el3_interrupt_handler => sgi_ras_intr_handler => spm_sp_call (enters/exit the SP to handle the injected RAS error) => sdei_dispatch_event > > se = get_event_entry(map); > if (!can_sdei_state_trans(se, DO_DISPATCH)) > return -1; > > p *map > $6 = {ev_num = 804, intr = 0, map_flags = 112, reg_count = 0, lock = {lock = 0}} > p *se > $4 = {ep = 0, arg = 0, affinity = 0, reg_flags = 0, state = 0 '\0'} > > sdei_dispatch_event exits in error at this stage, this does not seem a correct behavior. > The SDEI handler is not called in NS world and context remains unchanged. > The interrupt handler blindly returns to S-EL1 SP context at same location where it last exited. > sgi_ras_intr_handler => ehf_el3_interrupt_handler => vector_entry fiq_aarch64 => el3_exit => re-enters the SP with X0=0xC4000061 > SP then exits but the EL3 context has not been setup for SP entry leading to crash. > > IMO there is an issue around mapping SDEI event number to RAS interrupt number leading to sdei_dispatch_event exiting early. > > Regards, > Olivier. > > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Matteo Carlini via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 14 April 2020 10:41 > To: 吴斌(郅隆); tf-a(a)lists.trustedfirmware.org; Thomas Abraham; Deepak Pandey > Cc: nd > Subject: Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > > Looping-in Thomas & Deepak, responsible for the RD-N1 landing team platforms releases. They might be able to help. > > Thanks > Matteo > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of ??(??) via TF-A > Sent: 14 April 2020 06:47 > To: TF-A <tf-a-bounces(a)lists.trustedfirmware.org>; Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > > Hi RagHu, > > Really appreciate your help. > > I was downloaded this software stack from git.linaro.org. This software stack include ATF, kernel, edk2 and so on. > The user guide i used from linaro is:https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms… > > 1) What platform you are running on? Can this issue be reproduced > outside your testing environment, perhaps on FVP or QEMU? > A: I am running on ARM N1-Edge FVP platform. It can reproduced on this FVP platform. > > 2) What version of TF-A and StandaloneMM is being used? Preferably the > commit-id, so that we can be sure we are looking at the same code. > A: TF-A: https://git.linaro.org/landing-teams/working/arm/arm-tf.git tag:RD-INFRA-20191024-RC0 > StandloneMM seems build from edk2 & edk2-platform. so i just put edk2 and edk2-platform version information. if anything i missed, please let me know. > edk2: https://git.linaro.org/landing-teams/working/arm/edk2.git<https://git.linaro.org/landing-teams/working/arm/edk2.git/> tag:RD-INFRA-20191024-RC0 > edk2-platform: https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git<https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git/> tag:RD-INFRA-20191024-RC0 > > 3) What version of the kernel and sdei driver is being used? > A: kernel-release: https://git.linaro.org/landing-teams/working/arm/kernel-release.git tag:RD-INFRA-20191024-RC0 > The sdei driver was included in kernel, do i need to provide sdei driver version? If need please let me know. > 4) I can't tell from looking at the log but do you know if writing 0x123 > to sde_ras_poison causes a DMC620 interrupt or an SError or external > abort through memory access ? > A: Sorry, linaro only refered it will inject the DMC-620 single-bit RAS error. So I am also not sure which exception type it will trigger. > > BRs， > Bin Wu > > ------------------原始邮件 ------------------ > 发件人:TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> > 发送时间:Tue Apr 14 01:25:47 2020 > 收件人:Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > 主题:Re: [TF-A] [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed > Hello, > > >>Does BL31 need to send 0xC4000061 event to BL32 again? > > I don't think it will. It is really odd that > 0xC4000061(SP_EVENT_COMPLETE_AARCH64) ever reaches the BL32/MM handler. > This is from looking at the upstream code quickly but it definitely > depends on the platform you are running, what version of TF-A you are > using, build options used. Is it possible that the unhandled exception > is occurring after successful handling of the DMC620 error but there is > a following issue that occurs right after, causing the crash? > From the register dump it looks like there was an Instruction abort > exception at address 0 while running in EL3. Something seems to have > gone seriously wrong to have 0xC4000061 ever go back to BL32 and to get > an instruction abort at address 0. > > >>Does current TF-A support to run RAS test? It seems BL31 will crash. > See above. The answer really depends on the factors mentioned above. > > The following would be helpful to know: > 1) What platform you are running on? Can this issue be reproduced > outside your testing environment, perhaps on FVP or QEMU? > 2) What version of TF-A and StandaloneMM is being used? Preferably the > commit-id, so that we can be sure we are looking at the same code. > 3) What version of the kernel and sdei driver is being used? > 4) I can't tell from looking at the log but do you know if writing 0x123 > to sde_ras_poison causes a DMC620 interrupt or an SError or external > abort through memory access ? > > Thanks > Raghu > > > On 4/13/20 12:16 AM, 吴斌(郅隆) via TF-A wrote: >> Dear Friends, >> >> I am using TF-A to test RAS feature. >> When I triggered DMC620 RAS error in Linux(echo 0x123 > >> /sys/kernel/debug/sdei_ras_poison). >> BL32 will recieve >> UnRecognized Event - 0xC4000061(SP_EVENT_COMPLETE_AARCH64) and finally >> BL31 crashed. >> >> In my understanding, this 0xC4000061 should consumed by BL31, not send >> it to BL32 again. >> >> A piece of error log as below: >> >> ************************************* >> >> CperWrite - CperAddress@0xFF610064 >> CperWrite - 1 Section@FFBE91A8, Length 80, SectionType@FFBE9138 >> CperWrite - Got Error Section: Platform Memory. >> MmEntryPoint Done >> Received delegated event >> X0 : 0xC4000061 >> X1 : 0x0 >> X2 : 0x0 >> X3 : 0x0 >> Received event - 0xC4000061 on cpu 0 >> UnRecognized Event - 0xC4000061 >> Failed delegated event 0xC4000061, Status 0x2 >> Unhandled Exception in EL3. >> x30 = 0x0000000000000000 >> x0 = 0x00000000ff007e00 >> x1 = 0xfffffffffffffffe >> x2 = 0x00000000600003c0 >> x3 = 0x0000000000000000 >> x4 = 0x0000000000000000 >> x5 = 0x0000000000000000 >> x6 = 0x00000000ff015080 >> x7 = 0x0000000000000000 >> x8 = 0x00000000c4000061 >> x9 = 0x0000000000000021 >> x10 = 0x0000000000000040 >> x11 = 0x00000000ff00f2b0 >> x12 = 0x00000000ff0118c0 >> x13 = 0x0000000000000002 >> x14 = 0x00000000ff016b70 >> x15 = 0x00000000ff003f20 >> x16 = 0x0000000000000044 >> x17 = 0x00000000ff010430 >> x18 = 0x0000000000000e3c >> x19 = 0x0000000000000000 >> More error log please refer to attachment. >> >> My question is, >> 1. Does BL31 need to send 0xC4000061 event to BL32 again? >> 2. Does current TF-A support to run RAS test? It seems BL31 will crash. >> >> Appreciate your help. >> >> BRs， >> Bin Wu >> > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 5 months

1
0
0 0

Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by Olivier.Deprez＠arm.com

Hi Bin Wu, Here's an early observation. On receiving the RAS fiq interrupt the following occurs: ehf_el3_interrupt_handler => sgi_ras_intr_handler => spm_sp_call (enters/exit the SP to handle the injected RAS error) => sdei_dispatch_event se = get_event_entry(map); if (!can_sdei_state_trans(se, DO_DISPATCH)) return -1; p *map $6 = {ev_num = 804, intr = 0, map_flags = 112, reg_count = 0, lock = {lock = 0}} p *se $4 = {ep = 0, arg = 0, affinity = 0, reg_flags = 0, state = 0 '\0'} sdei_dispatch_event exits in error at this stage, this does not seem a correct behavior. The SDEI handler is not called in NS world and context remains unchanged. The interrupt handler blindly returns to S-EL1 SP context at same location where it last exited. sgi_ras_intr_handler => ehf_el3_interrupt_handler => vector_entry fiq_aarch64 => el3_exit => re-enters the SP with X0=0xC4000061 SP then exits but the EL3 context has not been setup for SP entry leading to crash. IMO there is an issue around mapping SDEI event number to RAS interrupt number leading to sdei_dispatch_event exiting early. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Matteo Carlini via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 14 April 2020 10:41 To: 吴斌(郅隆); tf-a(a)lists.trustedfirmware.org; Thomas Abraham; Deepak Pandey Cc: nd Subject: Re: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Looping-in Thomas & Deepak, responsible for the RD-N1 landing team platforms releases. They might be able to help. Thanks Matteo From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of ??(??) via TF-A Sent: 14 April 2020 06:47 To: TF-A <tf-a-bounces(a)lists.trustedfirmware.org>; Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] 回复：Re: [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Hi RagHu, Really appreciate your help. I was downloaded this software stack from git.linaro.org. This software stack include ATF, kernel, edk2 and so on. The user guide i used from linaro is:https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms… 1) What platform you are running on? Can this issue be reproduced outside your testing environment, perhaps on FVP or QEMU? A: I am running on ARM N1-Edge FVP platform. It can reproduced on this FVP platform. 2) What version of TF-A and StandaloneMM is being used? Preferably the commit-id, so that we can be sure we are looking at the same code. A: TF-A: https://git.linaro.org/landing-teams/working/arm/arm-tf.git tag:RD-INFRA-20191024-RC0 StandloneMM seems build from edk2 & edk2-platform. so i just put edk2 and edk2-platform version information. if anything i missed, please let me know. edk2: https://git.linaro.org/landing-teams/working/arm/edk2.git<https://git.linaro.org/landing-teams/working/arm/edk2.git/> tag:RD-INFRA-20191024-RC0 edk2-platform: https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git<https://git.linaro.org/landing-teams/working/arm/edk2-platforms.git/> tag:RD-INFRA-20191024-RC0 3) What version of the kernel and sdei driver is being used? A: kernel-release: https://git.linaro.org/landing-teams/working/arm/kernel-release.git tag:RD-INFRA-20191024-RC0 The sdei driver was included in kernel, do i need to provide sdei driver version? If need please let me know. 4) I can't tell from looking at the log but do you know if writing 0x123 to sde_ras_poison causes a DMC620 interrupt or an SError or external abort through memory access ? A: Sorry, linaro only refered it will inject the DMC-620 single-bit RAS error. So I am also not sure which exception type it will trigger. BRs， Bin Wu ------------------原始邮件 ------------------ 发件人:TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> 发送时间:Tue Apr 14 01:25:47 2020 收件人:Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> 主题:Re: [TF-A] [RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed Hello, >>Does BL31 need to send 0xC4000061 event to BL32 again? I don't think it will. It is really odd that 0xC4000061(SP_EVENT_COMPLETE_AARCH64) ever reaches the BL32/MM handler. This is from looking at the upstream code quickly but it definitely depends on the platform you are running, what version of TF-A you are using, build options used. Is it possible that the unhandled exception is occurring after successful handling of the DMC620 error but there is a following issue that occurs right after, causing the crash? From the register dump it looks like there was an Instruction abort exception at address 0 while running in EL3. Something seems to have gone seriously wrong to have 0xC4000061 ever go back to BL32 and to get an instruction abort at address 0. >>Does current TF-A support to run RAS test? It seems BL31 will crash. See above. The answer really depends on the factors mentioned above. The following would be helpful to know: 1) What platform you are running on? Can this issue be reproduced outside your testing environment, perhaps on FVP or QEMU? 2) What version of TF-A and StandaloneMM is being used? Preferably the commit-id, so that we can be sure we are looking at the same code. 3) What version of the kernel and sdei driver is being used? 4) I can't tell from looking at the log but do you know if writing 0x123 to sde_ras_poison causes a DMC620 interrupt or an SError or external abort through memory access ? Thanks Raghu On 4/13/20 12:16 AM, 吴斌(郅隆) via TF-A wrote: > Dear Friends, > > I am using TF-A to test RAS feature. > When I triggered DMC620 RAS error in Linux(echo 0x123 > > /sys/kernel/debug/sdei_ras_poison). > BL32 will recieve > UnRecognized Event - 0xC4000061(SP_EVENT_COMPLETE_AARCH64) and finally > BL31 crashed. > > In my understanding, this 0xC4000061 should consumed by BL31, not send > it to BL32 again. > > A piece of error log as below: > > ************************************* > > CperWrite - CperAddress@0xFF610064 > CperWrite - 1 Section@FFBE91A8, Length 80, SectionType@FFBE9138 > CperWrite - Got Error Section: Platform Memory. > MmEntryPoint Done > Received delegated event > X0 : 0xC4000061 > X1 : 0x0 > X2 : 0x0 > X3 : 0x0 > Received event - 0xC4000061 on cpu 0 > UnRecognized Event - 0xC4000061 > Failed delegated event 0xC4000061, Status 0x2 > Unhandled Exception in EL3. > x30 = 0x0000000000000000 > x0 = 0x00000000ff007e00 > x1 = 0xfffffffffffffffe > x2 = 0x00000000600003c0 > x3 = 0x0000000000000000 > x4 = 0x0000000000000000 > x5 = 0x0000000000000000 > x6 = 0x00000000ff015080 > x7 = 0x0000000000000000 > x8 = 0x00000000c4000061 > x9 = 0x0000000000000021 > x10 = 0x0000000000000040 > x11 = 0x00000000ff00f2b0 > x12 = 0x00000000ff0118c0 > x13 = 0x0000000000000002 > x14 = 0x00000000ff016b70 > x15 = 0x00000000ff003f20 > x16 = 0x0000000000000044 > x17 = 0x00000000ff010430 > x18 = 0x0000000000000e3c > x19 = 0x0000000000000000 > More error log please refer to attachment. > > My question is, > 1. Does BL31 need to send 0xC4000061 event to BL32 again? > 2. Does current TF-A support to run RAS test? It seems BL31 will crash. > > Appreciate your help. > > BRs， > Bin Wu > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 5 months

1
0
0 0

Trusted Firmware-A & TF-A tests version 2.3 is now available

by Bipin Ravi

Hi all, Trusted Firmware-A and TF-A tests version 2.3 is now available and can be found here: TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.3 TF-A-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.3 Please refer to the readme and change log for further information. Thanks & best regards, [cid:image001.jpg@01D6170F.64702DF0] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Bipin.Ravi@arm.com> | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

5 years, 5 months

1
0
0 0

Re: [TF-A] Event Log for Measured Boot

by Alexei Fedorov

Hi Raghu and Varun, This patch is a complete, tested and verified reference implementation for FVP platform. Splitting it will create a set of separate non-buildable patches causing more complexity in following and understanding the code changes and dependencies. The whole patch with all the code present in it should be reviewed anyway, and the time spent will be less than the time used for reviewing separate patches (mass defect). Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 02 April 2020 05:11 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Event Log for Measured Boot Hi Alexei, I second Varun on this. The patch is huge. I recommend breaking it up into multiple commits. I've reviewed it but since it is a large patch, it might require a few more sittings to grasp all the changes(which also means there may be some stupid review comments :)). -Raghu On 3/31/20 10:28 AM, Varun Wadekar via TF-A wrote: > Hello Alexei, > > Just curious, the patch is huge and will take some time to review. Do > you expect this change to be merged before the v2.3 release? > > -Varun > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Alexei Fedorov via TF-A > *Sent:* Tuesday, March 31, 2020 7:19 AM > *To:* tf-a(a)lists.trustedfirmware.org > *Subject:* [TF-A] Event Log for Measured Boot > > *External email: Use caution opening links or attachments* > > Hi, > > Please review and provide your comments for the patch which adds > > Event Log generation for the Measured Boot. > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3806 > > Thanks. > > Alexei > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy > the information in any medium. Thank you. > > ------------------------------------------------------------------------ > This email message is for the sole use of the intended recipient(s) and > may contain confidential information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all > copies of the original message. > ------------------------------------------------------------------------ > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 5 months

2
1
0 0

Re: [TF-A] [RFC] isolation between runtime BL33 services and OS

by Olivier.Deprez＠arm.com

Hi, If buffers are to be consumed by NWd only, it's probably better to contain the isolation at NS-EL2 (through Stage-2 MMU mapping). Though from your statements I'm not clear if you wish to use an hypervisor, or not? If yes, which implementation or kind do you want to use? If not, I wonder if you could re-use OS facilities like shared mem with different permissions for two child processes (might be tricky)? I don't think execute-only regions exist in Cortex-A (unless implementing additional hardware). If executable it's probably also readable. Maybe you meant execute-never? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of François Ozog via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 20 April 2020 13:45 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [RFC] isolation between runtime BL33 services and OS Hi, I am trying to identify a mechanism to enforce a form of two-way isolation between BL33 runtime services in OS, for instance: - a pair of 2MB areas that could be RO by one entity and RW by the other - an execute only BL33 2MB area? This is similar to hypervisor except it only deals with memory, no vCPU, no GIC virtualization... Could EL3 or EL2 install protective mappings ? BL33 could ask either EL2 hypervisor or SecureMonitor to actually install them. Cordially, FF -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 5 months

2
1
0 0

[RFC] isolation between runtime BL33 services and OS

by François Ozog

Hi, I am trying to identify a mechanism to enforce a form of two-way isolation between BL33 runtime services in OS, for instance: - a pair of 2MB areas that could be RO by one entity and RW by the other - an execute only BL33 2MB area? This is similar to hypervisor except it only deals with memory, no vCPU, no GIC virtualization... Could EL3 or EL2 install protective mappings ? BL33 could ask either EL2 hypervisor or SecureMonitor to actually install them. Cordially, FF

5 years, 5 months

1
0
0 0

TrustedFirmware's Hafnium mailing list

by Olivier Deprez

Hi, As part of integrating Hafnium within Trusted Firmware projects, a new mailing list has been created: https://lists.trustedfirmware.org/mailman/listinfo/hafnium You can register this list to participate to Hafnium in general, and coming S-EL2 firmware design discussions. Regards, Olivier.

5 years, 5 months

1
0
0 0

Re: [TF-A] Design proposal: firmware debugfs interface

by Olivier Deprez

Hi, To complement the DebugFS design proposal document, here is a corresponding TF-A patchset: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2422 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2431 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2432 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2423 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2421 An associated TFTF test case illustrates the usage: https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/2433 Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 25 October 2019 15:30 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Design proposal: firmware debugfs interface Hi All, We are proposing a new firmware debug interface in the form of a "debug filesystem". The intent is to expose live firmware data or firmware driver HAL to the upper layers, in debug builds. For people interested, please review and comment the design proposal: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2381 The design is not closed, the intent is to collect opinions, and have a discussion on options and implications. Thanks & Regards, Olivier. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 5 months

1
1
0 0

Re: [TF-A] Linux as BL33

by Ash Wilding

Hi @François<mailto:francois.ozog@linaro.org>, <quote> Now, I changed U-Boot to Image, added code to ensure arg0 is 0 (DTB) but Linux does not start (zero printk visible). I don't find kernel text base anymore, may be it disappeared: any suggestion to get the kernel start when loaded at 64KB offset? the kernel image with embedded initrd is 10MB, SRAM is at 64MB so there should be enough space to decompress initrd... </quote> I recommend reading through the arm64 Linux booting requirements if you haven’t already; you’ll need to ensure all of those conditions are met before entering the kernel [1]. For example have you correctly set text_offset in the image header? <quote> u32 code0; /* Executable code */ u32 code1; /* Executable code */ u64 text_offset; /* Image load offset, little endian */ u64 image_size; /* Effective Image size, little endian */ u64 flags; /* kernel flags, little endian */ u64 res2 = 0; /* reserved */ u64 res3 = 0; /* reserved */ u64 res4 = 0; /* reserved */ u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ u32 res5; /* reserved (used for PE COFF offset) */ </quote> <quote> The Image must be placed text_offset bytes from a 2MB aligned base address anywhere in usable system RAM and called there. </quote> Kind regards, Ash. [1] https://elixir.bootlin.com/linux/latest/source/Documentation/arm64/booting.… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 5 months

2
2
0 0

Re: [TF-A] sp select in atf

by Ash Wilding

Hi Feng, This is standard practice for operating systems, hypervisors, and firmware running on Armv8-A systems. A key distinction between SPSel,#0 and SPSel,#1 is that you can tell which stack pointer you were using when you took an exception as they correspond to different offsets in the vector table. Often times, taking an exception from the same EL when using SPSel,#0 is non-terminal whereas taking an exception from the same EL when already using SPSel,#1 is considered terminal. Take for example the scenario where your operating system, hypervisor, or firmware is running some task/thread code at EL1/EL2/EL3 and runs out of stack space, triggering a translation fault and attempting to stack some data (we’ll probably be using unmapped guard pages at the stack boundaries). The first thing the exception handler will try to do is stack the GPRs. If the reason you took the exception is because the stack pointed to by SP_EL1/2/3 has itself overflowed, this attempt to stack the GPRs will itself cause a translation fault and you’ll get stuck in a recursive exception. In contrast, if the reason you took the exception is because the stack pointed to by SP_EL0 has overflowed, the exception handler will successfully stack the GPRs to the SP_EL1/2/3 stack and be able to diagnose + log what went wrong before rebooting gracefully. Hope that helps, Ash. From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chen Feng via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Chen Feng <puck.chen(a)hisilicon.com> Date: Friday, 17 April 2020 at 09:02 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org>, Alexei Fedorov <Alexei.Fedorov(a)arm.com>, Yatharth Kochar <Yatharth.Kochar(a)arm.com>, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> Cc: "puck.chen(a)hisilicon.com" <puck.chen(a)hisilicon.com>, "lizhong11(a)hisilicon.com" <lizhong11(a)hisilicon.com> Subject: [TF-A] sp select in atf Hello all, I see the atf use different sp, and special for smc64 it use the sp_el0. So for the unhandled-exception handler, it must switch to sp_el0 to do the back-trace-dump. Since it default used sp_el3 when exception happen. My question here is why using different sp in atf code? Just use the sp_el3 for all scenes seems more simpler. Cheers, - feng -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A