- TF-A - lists.trustedfirmware.org

TF-A Tech Forum Agenda @ Thr 5th November 2020 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 5th November 2020 16:00 – 17:00 (GMT). Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from BST. A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * TF-A Tests Framework Overview * Presented by Varun Wadekar * Summary * Trusted Firmware-A Tests (TF-A Tests) is a suite of baremetal tests to exercise the Trusted Firmware-A (TF-A) features from the Normal World. * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

5 years, 11 months

1
0
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

5 years, 11 months

1
0
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by Ruchika Gupta

Hi, *For [1] - Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood.* You can check the implementation at https://github.com/microsoft/MSRSec This compiles for aarch64. I had a few queries for chips having physical TPM. Case 1. Should all entities doing the measurement (BL1, BL2) have the TPM driver to extend the measurements as they are done. This would be the most secure flow. Case 2. If BL1 and BL2 don't have the TPM driver as mentioned in Case 1 above, who would be responsible for extending the measurements for secure world entities. -- Should there be a TPM driver in Secure EL0/EL1 which does this ? -- Event log is also passed to the BL33. In case there is no TPM driver at all in the secure world - is it expected that BL33 should extend the measurements in PCR ? Regards, Ruchika On Mon, 26 Oct 2020 at 21:03, Stuart Yoder via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Regarding measuring TB_FW_CONFIG-- > > BL1 could measure the unmodified TB_FW_CONFIG image as it was loaded from > flash. It could then update TB_FW_CONFIG with that measurement which > reflects the image as it was on flash. This could allow detection of > tampering with flash. I would recommend doing this, as TB_FW_CONFIG is > critical data. > > BL2 could make a measurement of the TB_FW_CONFIG image as it was passed to > it in memory. > > Thanks, > Stuart > > > On 10/26/20 6:16 AM, Alexei Fedorov wrote: > > Hi Javer, > > Please see my comments below. > > [3] Provide platform hooks in tpm_record_measurement function for a > platform to actually extend those measurements to a physical TPM right when > they are measured. > > These hooks can be implemented in the next phase #2 of Measured Boot > implementation. > > [4] On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should > also be measured since they are images being loaded as well. See > arm_bl1_setup.c where these images are loaded but not measured(unless I’m > missing something). > > FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2. > BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG. > It can also pass FW_CONFIG hash in the same DTB, but it is not clear how > own TB_FW_CONFIG hash can be passed in itself. > > Stuart, do you have opinion on that? > > Regards. > > Alexei > ------------------------------ > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> > <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Javier Almansa > Sobrino via TF-A <tf-a(a)lists.trustedfirmware.org> > <tf-a(a)lists.trustedfirmware.org> > *Sent:* 26 October 2020 10:25 > *To:* raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> > <raghu.ncstate(a)icloud.com> > *Cc:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] Questions raised about Measured Boot + fTPM test > case > > Hi Raghu, > > Thank you very much for your comments and for your feedback. > > With regards to the (f)TPM service and as discussed during the last TF-A > Tech Forum call, we will discuss internally the need of a new > implementation, probably after the next TF-A release, and we will schedule > the work (in case we decide to go ahead with it) for the upcoming months. > We will announce any decision we make through the mailing list and/or on > future TF-A Tech Forum calls . > > Regarding to changes to TF-A to include extra functionality/APIs/hooks, I > guess my colleague Alexei can provide further details about the next > features planned for Measured Boot, if any. > > To finish, I would just like to clarify one of the questions raised on > your email: > > [1] Would be good if the test infrastructure(the TPM TA) can compile in > AARCH64. I thought I heard on the tf-a call that there already is a > Microsoft FW TPM port for aarch64 already. Please let me know if I > misunderstood. > > > - Microsoft has a reference implementation of the TPM 2.0 > specification. That implementation is in the form of an architecture > agnostic library that implements the specification. Along with the library, > there are a couple of example applications for different platforms built > around the former, one of them being the fTPM we used for testing. That > application was written for AARCH32 and seemed to be outdated (I don't know > if it was abandoned, actually), so we updated it and added support for > Measured Boot to it. > > > Best regards, > Javier > > -----Original Message----- > *From*: raghu.ncstate(a)icloud.com > *To*: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino(a)arm.com > <'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino(a)arm.com%3e>> > *Cc*: tf-a(a)lists.trustedfirmware.org > *Subject*: RE: [TF-A] Questions raised about Measured Boot + fTPM test > case > *Date*: Sun, 25 Oct 2020 14:31:10 -0700 > > Hi Javier, > > > > As discussed during the TF-A call, here are some suggestions/feedback that > can be incorporated when time permits based on priorities, schedule, > resources etc: > > 1. Would be good if the test infrastructure(the TPM TA) can compile in > AARCH64. I thought I heard on the tf-a call that there already is a > Microsoft FW TPM port for aarch64 already. Please let me know if I > misunderstood. > 2. Would be good if the TPM TA works on FF-A as opposed to proprietary > OPTEE API’s. > 3. Provide platform hooks in tpm_record_measurement function for a > platform to actually extend those measurements to a physical TPM right when > they are measured. This is a requirement from a security perspective to not > wait until the tpm TA is loaded to be able to extend the measurements into > a tpm. I understand this can be done in the platform hook that calls > tpm_record_measurement but it is convenient place to put tpm related > platform hooks. > 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should > also be measured since they are images being loaded as well. See > arm_bl1_setup.c where these images are loaded but not measured(unless I’m > missing something). > > > > Thanks > > Raghu > > > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> > <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Javier Almansa > Sobrino via TF-A > *Sent:* Friday, October 9, 2020 10:51 AM > *To:* tf-a(a)lists.trustedfirmware.org > *Subject:* [TF-A] Questions raised about Measured Boot + fTPM test case > > > > Hello all, > > > > Following up the question raised yesterday during the TF-A Tech Forum with > regards to any modification needed on the Linux Kernel to run the test case > that I was presenting (Measured Boot + fTPM service), I double checked > today and I ran some tests on system and I can confirm that the test case > works with the mainline Linux Kernel, with no modification other than > enabling the driver on the DTB. > > > > The modules involved on the interaction with the fTPM (for this particular > example) are: > > > > * optee.ko: Allows communication between the REE (unsecure world), the > Trusted OS (secure world) and the tee-supplicant (unsecure world). > > * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a > char device. This also includes the reference implementation used on the > test case. > > > > In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 > TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. > > > > I would also like to highlight the following points: > > > > A) The test case is only meant to test the ability of the Measured Boot > Driver and a TPM 2.0 compliant device to interact with each other. As such, > we are not providing an fTPM meant to be used on a production environment. > Instead, we are using an existing reference implementation to which we > added support for Measured Boot to fulfil our needs for the test and use it > as a functional example. The implementation details on how to interact with > a particular TPM device (either firmware or discrete) can differ from the > ones used on the test case as those details can be platform dependent. For > example, we use an OPTEE TA fTPM on this example, but other platforms might > use a discrete TPM or an fTPM running on a different Trusted OS. > > > > B) As stated on the presentation, we are undergoing internal review of the > contributions done for the fTPM service to make it compatible with Measured > Boot. Once the review is completed and the changes merged into the TPM repo > mainline, we will update the TF-A documentation with instructions on how to > download and build all the components to run the tests manually. > > > > Please, let me know in case you have any more questions. > > > > Best regards, > > Javier > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

5 years, 11 months

3
2
0 0

Re: [TF-A] [Linaro-open-discussions] Extend TF-A with PSCI OS-initiated mode

by Matteo Carlini

Cross-posting to the TF-A mailing list as well for interested partners. > -----Original Message----- > From: Linaro-open-discussions <linaro-open-discussions-bounces@op- > lists.linaro.org> On Behalf Of Ulf Hansson via Linaro-open-discussions > Sent: 28 October 2020 15:45 > To: linaro-open-discussions(a)op-lists.linaro.org > Cc: Lauren Wehrmeister <Lauren.Wehrmeister(a)arm.com>; Lina Iyer > <ilina(a)codeaurora.org>; Dan Handley <Dan.Handley(a)arm.com>; Madhukar > Pappireddy <Madhukar.Pappireddy(a)arm.com>; Bhutada Harshad > <hbhutada(a)qti.qualcomm.com>; Gabriel FERNANDEZ > <gabriel.fernandez(a)st.com> > Subject: [Linaro-open-discussions] Extend TF-A with PSCI OS-initiated mode > > Hi all, > > In the Linux kernel v5.6, we introduced the basic support for PSCI OS-initiated > mode. Linaro is still working on evolving the support, step by step. > Additionally, we are helping some of our members with corresponding SoC > deployment, which is planned to continue for a while. > > Basically, the PSCI OS-initiated mode allows Linux to be in charge of idlestate > decisions for a group of CPUs (aka CPU cluster), which may share idlestates. > In some cases this enables improvements in regards to performance/energy, > but could also be used to help manage resources that may share power- > /clock-domains with CPUs. > > Moving forward, we are now planning to extend the corresponding PSCI > implementation in the Trusted Firmware-A (TF-A) with the OS-initiated mode, > together with our members and member engineers. Currently, only the > default PSCI platform-coordinated mode is supported by the TF-A. > > We seek for additional collaborations and input to the new project! > Please get in touch, if you have any feedback and/or find this project > interesting. > > Finally, a kickoff meeting is about to be scheduled and held within a few > weeks. Let me know if you want to join the discussions. > > Kind regards > Ulf Hansson, Linaro Kernel Working Group > -- > Linaro-open-discussions mailing list > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions

5 years, 11 months

1
0
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, I'm able to eliminate the warning using the -j .text and see the image load and run ok. The issue I am seeing is that the bsp I am using expects my bot loader bl31.bin to power on the UART and do the low level init that makes PCIe controller accessible. I think at exit from bl31.bin I don't have this initialization. Can you point me the TFA code to enable LPUART and make PCIe controller accessible in imx8qm before handoff to BL33 ? Regards Ravi > On Oct 28, 2020, at 11:33 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, Thanks for the hint. Yes, my App.bin image has a bunch of header info > and that's the root cause of the undef ARM instructions. I grabbed a pure ELF image > I built using the integrity compiler and see the following warning on trying to convert ELF to > raw binary on linux. The conversion is not permitted. Do I need some flags ? > > Regards > Ravi > > ravi:~/imx8qm/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin$ ./aarch64-none-elf-readelf -h ~/imx8qm/imx-mkimage/iMX8QM/example_app.elf > ELF Header: > Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF64 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: EXEC (Executable file) > Machine: AArch64 > Version: 0x1 > Entry point address: 0xffffff8080200000 > Start of program headers: 64 (bytes into file) > Start of section headers: 866208 (bytes into file) > Flags: 0x0 > Size of this header: 64 (bytes) > Size of program headers: 56 (bytes) > Number of program headers: 49 > Size of section headers: 64 (bytes) > Number of section headers: 78 > Section header string table index: 77 > > ravi:~/imx8qm/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/bin$ ./aarch64-none-elf-objcopy -O binary ~/imx8qm/imx-mkimage/iMX8QM/example_app.elf ~/imx8qm/imx-mkimage/iMX8QM/dummy.bin > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.text' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.rodata' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.rodata' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.example_virtual.data' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.boottable' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy: warning: writing section `.secinfo' at huge (ie negative) file offset > ./aarch64-none-elf-objcopy:/home/ravi/imx8qm/imx-mkimage/iMX8QM/dummy.bin[.example_virtual.text]: file truncated > > > > > > On Wed, Oct 28, 2020 at 10:09 AM Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > Hi Ravi, > > Is App.bin generated by the tool you use is a "pure" binary or contains some extra entries at the start of the image (e.g. 0x7F 0x45 0x4C 0x46 = "ELF" )? > This might also help: > https://stackoverflow.com/questions/49814470/u-boot-how-to-run-a-standalone… <https://stackoverflow.com/questions/49814470/u-boot-how-to-run-a-standalone…> > > Alexei > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > Sent: 27 October 2020 22:03 > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > No, we don't see the same behavior when launching our hello world app (using Integrity178 rtos) > from U-boot. The only change uboot needed was related to size of the image (i don't have specifics about this change). > But, the hello app runs fine from U-boot printing normally on the imx8qm MEK board. > > I don't see this test app write to the UART launching from bl31.bin at 0x80020000. I can see the > handoff is successful setting a breakpoint at 0x80020000 from my Lauterbach debugger probe. > > The test app is prepared using the GHS tools (elf to bin) using gmemfile.exe and then uboot's mkimage > command: mkimage -A arm64 -O u-boot -T kernel -C none -a 0x80200000 -e 0x80200000 -n "INTEG" -d tmp.bin App.bin. > This generates the App.bin that tftpboots boots fine from any given address on my board. This very same image > does not work booting from bl31.bin. > > Can you suggest what could be going on ? > > Regards > Ravi > > > > > > On Oct 27, 2020, at 8:34 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > > > > Hi Ravi, > > > > It is good to know that you have some progress with your problem. > > > > "I'm seeing some undef instruction, etc, etc." > > Do you see the same behaviour when launching BL33 from U-Boot? > > > > Regards. > > Alexei > > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > > Sent: 26 October 2020 20:23 > > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > > Subject: Re: [TF-A] BL31 as bootloader > > > > Hi Alexei, Manish, > > > > I had some better luck with my debugger this time. I can see > > the handoff from bl31.bin (imx-atf) to BL33 entry point (0x80020000) > > in my debugger now. > > > > The problem was in setting up the debugger properly which was > > preventing me from seeing the breakpoint. My bad. > > > > Now, I can see the handoff and execution of instruction of the > > test app. This app is an integrity178 app and I'm seeing some undef > > instruction, etc, etc. Likely specific to the rtos we are using for this app. > > So, I will follow up on that end. Thanks for your debug support and > > helping me experiment with TFA for our product. > > > > Regards > > Ravi > > > > > >> On Oct 26, 2020, at 4:44 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >> > >> Hi Ravi > >> > >> As you can see in debugger that memory at 0x80020000 address is populated correctly, can you set a breakpoint at it to check if execuion reaches it? If you cannot set a breakpoint I would suggest to add a few assembler instructions in the start of your BL33 entry point to write any specific character, e.g. '!' to debug UART data port and branch to the next instruction in an infinite loop with "b .". Seeing ! char on debug console would prove that control to BL33 image has been passed. > >> > >> Regards. > >> Alexei > >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >> Sent: 24 October 2020 22:48 > >> To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >> Subject: Re: [TF-A] BL31 as bootloader > >> > >> Hi Alexei, Manish, > >> > >> I instrumented the imx8QM platform code and saw normal execution with bl31_main() > >> exiting normally with entry point for my BL33 image. But, I haven't seen the handoff > >> work yet. Can you suggest what else I can try to debug this ? I have an image copied > >> at 0x80020000 from what I can see in the debugger. Thanks in advance. > >> > >> Regards > >> Ravi > >> > >> > >> > >> > >> On Fri, Oct 23, 2020 at 3:43 PM rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> wrote: > >> Hi Manish, > >> > >> I have been able to copy the test app (BL33) to entry point address 0x80020000. > >> I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf > >> makefile target to use the "-data" option as follows: > >> flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >> The -data option appears to copy the image at the 0x80020000 address. Now, I think we should > >> be able to handoff since PC (program counter) is set : > >> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); > >> > >> I don't see any serial console output using an image that works when using u-boot. I am not using > >> u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to > >> the App.bin ? At which BL31 function or module does the handoff occur ? > >> > >> I don't see my HW breakpoint trigger at location location 0x80020000. > >> > >> Regards > >> Ravi > >> > >>> On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>> > >>> Hi Manish, > >>> > >>> Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? > >>> Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). > >>> > >>> The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 > >>> to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming > >>> its some NXP firmware doing it. Do you know where it could be ? > >>> > >>> Regards > >>> Ravi > >>> > >>> > >>>> On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: > >>>> > >>>> Hi Ravi, > >>>> > >>>> This is normal behaviour when you RESET_TO_BL31. > >>>> The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. > >>>> Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. > >>>> > >>>> thanks > >>>> Manish > >>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>> Sent: 23 October 2020 05:08 > >>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>> Subject: Re: [TF-A] BL31 as bootloader > >>>> > >>>> Hi Alexei, Manish, > >>>> > >>>> I repeated the test (below) a few times and see the same result. > >>>> > >>>> (1) Do I need to copy my BL33 (non-secure) image from > >>>> flash.bin some how to RAM 0x80020000 entry point address ? > >>>> Is there any example of how to copy the flash.bin image ? I not sure > >>>> what address or where to copy it from. > >>>> > >>>> (2) Is there some existing debug code that I can use > >>>> to dump/print the ARMv8 RAM address space from inside > >>>> BL31.bin ? > >>>> > >>>> I only found some TF-A tf_log macros in debug.h. > >>>> I would like to dump some memory address contents > >>>> (like 0x80020000) from inside bl31.bin to console just for > >>>> debugging at run-time. > >>>> > >>>>> On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>>>> > >>>>> Hi Alexei, > >>>>> > >>>>> I captured the LOG_LEVEL=50 log (attached putty-ser0.log) from TF-A bl31.bin. > >>>>> I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) > >>>>> > >>>>> The flash.bin image I am running is constructed using imx-mkimage tool with the following target: > >>>>>> flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >>>>>> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >>>>> > >>>>> I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. > >>>>> > >>>>> I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). > >>>>>> diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c > >>>>>> index 92a2027dd..51afb13ea 100644 > >>>>>> --- a/bl31/bl31_main.c > >>>>>> > >>>>>> +++ b/bl31/bl31_main.c > >>>>>> @@ -147,6 +147,11 @@ void bl31_main(void) > >>>>>> * from BL31 > >>>>>> */ > >>>>>> bl31_plat_runtime_setup(); > >>>>>> + > >>>>>> + INFO("BL31: leaving bl31_main\n"); > >>>>>> + INFO("entering while(1)\n"); > >>>>>> + > >>>>>> + while (1) {}; > >>>>>> } > >>>>> It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at > >>>>> address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). > >>>>> See the debugger output. > >>>>> > >>>>> When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin > >>>>> copy the image from flash to RAM ? > >>>>> > >>>>> Can you suggest what could be going on ? > >>>>> > >>>>> Regards > >>>>> Ravi > >>>>> > >>>>> > >>>>> > >>>>>> On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>> > >>>>>> Hi Ravi, > >>>>>> > >>>>>> TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> > >>>>>> > >>>>>> You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. > >>>>>> Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. > >>>>>> > >>>>>> Regards. > >>>>>> Alexei > >>>>>> > >>>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>> Sent: 21 October 2020 19:59 > >>>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>> > >>>>>> Alexei, > >>>>>> > >>>>>> I don't have a DS-5 debugger setup/licensed. I am hoping > >>>>>> on getting something shortly. > >>>>>> > >>>>>> Can you point me to the TFTF image that I can use to > >>>>>> test the BL33 handoff ? > >>>>>> > >>>>>> Sorry, I'm not familiar at this time. > >>>>>> > >>>>>> Regards > >>>>>> Ravi > >>>>>> > >>>>>> > >>>>>>> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>> > >>>>>>> You can also use TFTF image as BL33. > >>>>>>> > >>>>>>> Alexei > >>>>>>> > >>>>>>> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>>>>> Sent: 21 October 2020 15:26 > >>>>>>> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>> > >>>>>>> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). > >>>>>>> > >>>>>>> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? > >>>>>>> - You can use a linux image and device tree to test it > >>>>>>> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function > >>>>>>> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" > >>>>>>> > >>>>>>> > >>>>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>>> Sent: 21 October 2020 12:12 > >>>>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > >>>>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>> > >>>>>>> Hi Alexei, Manish, > >>>>>>> > >>>>>>> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: > >>>>>>>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, > >>>>>>>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; > >>>>>>>> #endif > >>>>>>>> #endif > >>>>>>>> + // DEBUG ONLY - FIXME > >>>>>>>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > >>>>>>>> + > >>>>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); > >>>>>>>> > >>>>>>>> /* init the first cluster's cci slave interface */ > >>>>>>>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); > >>>>>>>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); > >>>>>>>> + > >>>>>>>> } > >>>>>>> But no luck. > >>>>>>> > >>>>>>> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? > >>>>>>> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? > >>>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> > >>>>>>>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>>> > >>>>>>>> Hi Ravi, > >>>>>>>> > >>>>>>>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: > >>>>>>>> > >>>>>>>> /* Populate entry point information for BL33 */ > >>>>>>>> SET_PARAM_HEAD(&bl33_image_ep_info, > >>>>>>>> PARAM_EP, > >>>>>>>> VERSION_1, > >>>>>>>> 0); > >>>>>>>> /* > >>>>>>>> * Tell BL31 where the non-trusted software image > >>>>>>>> * is located and the entry state information > >>>>>>>> */ > >>>>>>>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); > >>>>>>>> > >>>>>>>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); > >>>>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); > >>>>>>>> > >>>>>>>> Regards. > >>>>>>>> Alexei > >>>>>>>> > >>>>>>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> Sent: 21 October 2020 10:57 > >>>>>>>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> > >>>>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> Subject: Re: [TF-A] BL31 as bootloader > >>>>>>>> > >>>>>>>> Hi Manish, > >>>>>>>> > >>>>>>>> The test image should not have any dependency on device tree (dtb?) > >>>>>>>> for console init. > >>>>>>>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match > >>>>>>>> the MEK board. > >>>>>>>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) > >>>>>>>> as well but no luck. > >>>>>>>> I don't believe PC is getting set to the 0x80020000 entry point. > >>>>>>>> > >>>>>>>> The test image has validated with u-boot using these tftpboot settings: > >>>>>>>> setenv ipaddr x.x.x.x > >>>>>>>> setenv serverip x.x.x.x > >>>>>>>> tftpboot 0xf0000000 App.bin > >>>>>>>> bootm 0xf0000000 > >>>>>>>> > >>>>>>>> I don't see any console output on the screen running it with bl31.bin as below. > >>>>>>>> Is there any debug I can add somewhere to help troubleshoot? > >>>>>>>> > >>>>>>>> Can you please provide me instructions on where to patch this missing code : > >>>>>>>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" > >>>>>>>> I can try it to see if any change in behavior. > >>>>>>>> > >>>>>>>> Thanks in advance. > >>>>>>>> Regards > >>>>>>>> Ravi > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Ravi, > >>>>>>>> > > >>>>>>>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > >>>>>>>> > Also, does your "test image" depends on device tree for console initialization? > >>>>>>>> > > >>>>>>>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > >>>>>>>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > >>>>>>>> > > >>>>>>>> > thanks > >>>>>>>> > Manish > >>>>>>>> > > >>>>>>>> > ________________________________ > >>>>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Sent: 21 October 2020 00:10 > >>>>>>>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > >>>>>>>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Subject: Re: [TF-A] BL31 as bootloader > >>>>>>>> > > >>>>>>>> > Hi Alexei, > >>>>>>>> > > >>>>>>>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > >>>>>>>> > > >>>>>>>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > >>>>>>>> > > >>>>>>>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > >>>>>>>> > > >>>>>>>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > >>>>>>>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > >>>>>>>> > > >>>>>>>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > >>>>>>>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > >>>>>>>> > > >>>>>>>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > >>>>>>>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > >>>>>>>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > >>>>>>>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > >>>>>>>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > >>>>>>>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > >>>>>>>> > NOTICE: Non-secure Partitioning Succeeded > >>>>>>>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > >>>>>>>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > >>>>>>>> > INFO: bl31_platform_setup is called > >>>>>>>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > >>>>>>>> > INFO: BL31: Initializing runtime services > >>>>>>>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > >>>>>>>> > INFO: BL31: Preparing for EL3 exit to normal world > >>>>>>>> > INFO: Entry point address = 0x80020000 > >>>>>>>> > INFO: SPSR = 0x3c9 > >>>>>>>> > INFO: BL31: DEBUG: image_type is: normal > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > >>>>>>>> > Note, the same test image works fine using u-boot. > >>>>>>>> > > >>>>>>>> > Regards > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Alexei, > >>>>>>>> > > >>>>>>>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > >>>>>>>> > I will try it out and confirm. And, thanks for this suggestion. > >>>>>>>> > > >>>>>>>> > Regards > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > >>>>>>>> > > >>>>>>>> > Hi Ravi, > >>>>>>>> > > >>>>>>>> > Have you tried to use RESET_TO_BL31 build option for your platform? > >>>>>>>> > > >>>>>>>> > Regards. > >>>>>>>> > Alexei > >>>>>>>> > ________________________________ > >>>>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Sent: 07 October 2020 17:01 > >>>>>>>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > >>>>>>>> > Subject: [TF-A] BL31 as bootloader > >>>>>>>> > > >>>>>>>> > Hi, > >>>>>>>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > >>>>>>>> > > >>>>>>>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > >>>>>>>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > >>>>>>>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. > >>>>>>>> > This is without any security requirements or dependencies. > >>>>>>>> > > >>>>>>>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > >>>>>>>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > >>>>>>>> > 0x80020000 address ? > >>>>>>>> > > >>>>>>>> > Thanks in advance. > >>>>>>>> > Ravi > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > -- > >>>>>>>> > TF-A mailing list > >>>>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > -- > >>>>>>>> > TF-A mailing list > >>>>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > >>>>>>>> TF-A mailing list > >>>>>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>>>> > >>>>> > >>>>> -- > >>>>> TF-A mailing list > >>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > >>> > >>> -- > >>> TF-A mailing list > >>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 11 months

1
0
0 0

Re: [TF-A] BL31 as bootloader

by Alexei Fedorov

Hi Ravi As you can see in debugger that memory at 0x80020000 address is populated correctly, can you set a breakpoint at it to check if execuion reaches it? If you cannot set a breakpoint I would suggest to add a few assembler instructions in the start of your BL33 entry point to write any specific character, e.g. '!' to debug UART data port and branch to the next instruction in an infinite loop with "b .". Seeing ! char on debug console would prove that control to BL33 image has been passed. Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 24 October 2020 22:48 To: Ravi Kohli <rkohli2000(a)gmail.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I instrumented the imx8QM platform code and saw normal execution with bl31_main() exiting normally with entry point for my BL33 image. But, I haven't seen the handoff work yet. Can you suggest what else I can try to debug this ? I have an image copied at 0x80020000 from what I can see in the debugger. Thanks in advance. Regards Ravi On Fri, Oct 23, 2020 at 3:43 PM rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> wrote: Hi Manish, I have been able to copy the test app (BL33) to entry point address 0x80020000. I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf makefile target to use the "-data" option as follows: flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin The -data option appears to copy the image at the 0x80020000 address. Now, I think we should be able to handoff since PC (program counter) is set : bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); I don't see any serial console output using an image that works when using u-boot. I am not using u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to the App.bin ? At which BL31 function or module does the handoff occur ? I don't see my HW breakpoint trigger at location location 0x80020000. Regards Ravi On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Manish, Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming its some NXP firmware doing it. Do you know where it could be ? Regards Ravi On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: Hi Ravi, This is normal behaviour when you RESET_TO_BL31. The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. thanks Manish ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 23 October 2020 05:08 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I repeated the test (below) a few times and see the same result. (1) Do I need to copy my BL33 (non-secure) image from flash.bin some how to RAM 0x80020000 entry point address ? Is there any example of how to copy the flash.bin image ? I not sure what address or where to copy it from. (2) Is there some existing debug code that I can use to dump/print the ARMv8 RAM address space from inside BL31.bin ? I only found some TF-A tf_log macros in debug.h. I would like to dump some memory address contents (like 0x80020000) from inside bl31.bin to console just for debugging at run-time. On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Alexei, I captured the LOG_LEVEL=50 log (attached putty-ser0.log<https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) The flash.bin image I am running is constructed using imx-mkimage<https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c index 92a2027dd..51afb13ea 100644 --- a/bl31/bl31_main.c +++ b/bl31/bl31_main.c @@ -147,6 +147,11 @@ void bl31_main(void) * from BL31 */ bl31_plat_runtime_setup(); + + INFO("BL31: leaving bl31_main\n"); + INFO("entering while(1)\n"); + + while (1) {}; } It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). See the debugger output<https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin copy the image from flash to RAM ? Can you suggest what could be going on ? Regards Ravi On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. Regards. Alexei ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 21 October 2020 19:59 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Alexei, I don't have a DS-5 debugger setup/licensed. I am hoping on getting something shortly. Can you point me to the TFTF image that I can use to test the BL33 handoff ? Sorry, I'm not familiar at this time. Regards Ravi On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: You can also use TFTF image as BL33. Alexei ________________________________ From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Sent: 21 October 2020 15:26 To: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? - You can use a linux image and device tree to test it Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" ________________________________ From: rkohli2000 gmail <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> Sent: 21 October 2020 12:12 To: Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, Manish, I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; #endif #endif + // DEBUG ONLY - FIXME + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); + SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); /* init the first cluster's cci slave interface */ cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); + } But no luck. Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? Thanks. On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: /* Populate entry point information for BL33 */ SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); /* * Tell BL31 where the non-trusted software image * is located and the entry state information */ bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 21 October 2020 10:57 To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] BL31 as bootloader Hi Manish, The test image should not have any dependency on device tree (dtb?) for console init. I used the NXP provided imx8qm-mek-ca53.dtb file which should match the MEK board. I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) as well but no luck. I don't believe PC is getting set to the 0x80020000 entry point. The test image has validated with u-boot using these tftpboot settings: setenv ipaddr x.x.x.x setenv serverip x.x.x.x tftpboot 0xf0000000 App.bin bootm 0xf0000000 I don't see any console output on the screen running it with bl31.bin as below. Is there any debug I can add somewhere to help troubleshoot? Can you please provide me instructions on where to patch this missing code : "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" I can try it to see if any change in behavior. Thanks in advance. Regards Ravi On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: > > Hi Ravi, > > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > Also, does your "test image" depends on device tree for console initialization? > > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > > thanks > Manish > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Sent: 21 October 2020 00:10 > To: Ravi Kohli <rkohli2000(a)gmail.com<mailto:rkohli2000@gmail.com>> > Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > NOTICE: Non-secure Partitioning Succeeded > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > INFO: bl31_platform_setup is called > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x80020000 > INFO: SPSR = 0x3c9 > INFO: BL31: DEBUG: image_type is: normal > > > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > Note, the same test image works fine using u-boot. > > Regards > Ravi > > > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: > > Hi Alexei, > > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > I will try it out and confirm. And, thanks for this suggestion. > > Regards > Ravi > > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: > > Hi Ravi, > > Have you tried to use RESET_TO_BL31 build option for your platform? > > Regards. > Alexei > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Sent: 07 October 2020 17:01 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: [TF-A] BL31 as bootloader > > Hi, > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > specify this container image with both bl31.bin and a separate custom app at a give flash address. > This is without any security requirements or dependencies. > > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > 0x80020000 address ? > > Thanks in advance. > Ravi > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- 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, 11 months

2
6
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by Alexei Fedorov

Hi Javer, Please see my comments below. [3] Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. These hooks can be implemented in the next phase #2 of Measured Boot implementation. [4] On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2. BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG. It can also pass FW_CONFIG hash in the same DTB, but it is not clear how own TB_FW_CONFIG hash can be passed in itself. Stuart, do you have opinion on that? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Javier Almansa Sobrino via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 26 October 2020 10:25 To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Questions raised about Measured Boot + fTPM test case Hi Raghu, Thank you very much for your comments and for your feedback. With regards to the (f)TPM service and as discussed during the last TF-A Tech Forum call, we will discuss internally the need of a new implementation, probably after the next TF-A release, and we will schedule the work (in case we decide to go ahead with it) for the upcoming months. We will announce any decision we make through the mailing list and/or on future TF-A Tech Forum calls . Regarding to changes to TF-A to include extra functionality/APIs/hooks, I guess my colleague Alexei can provide further details about the next features planned for Measured Boot, if any. To finish, I would just like to clarify one of the questions raised on your email: [1] Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. * Microsoft has a reference implementation of the TPM 2.0 specification. That implementation is in the form of an architecture agnostic library that implements the specification. Along with the library, there are a couple of example applications for different platforms built around the former, one of them being the fTPM we used for testing. That application was written for AARCH32 and seemed to be outdated (I don't know if it was abandoned, actually), so we updated it and added support for Measured Boot to it. Best regards, Javier -----Original Message----- From: raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> To: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino(a)arm.com<mailto:'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino(a)arm.com%3e>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] Questions raised about Measured Boot + fTPM test case Date: Sun, 25 Oct 2020 14:31:10 -0700 Hi Javier, As discussed during the TF-A call, here are some suggestions/feedback that can be incorporated when time permits based on priorities, schedule, resources etc: 1. Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. 2. Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s. 3. Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. This is a requirement from a security perspective to not wait until the tpm TA is loaded to be able to extend the measurements into a tpm. I understand this can be done in the platform hook that calls tpm_record_measurement but it is convenient place to put tpm related platform hooks. 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Javier Almansa Sobrino via TF-A Sent: Friday, October 9, 2020 10:51 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Questions raised about Measured Boot + fTPM test case Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

5 years, 11 months

2
1
0 0

Re: [TF-A] Questions raised about Measured Boot + fTPM test case

by raghu.ncstate＠icloud.com

Hi Javier, As discussed during the TF-A call, here are some suggestions/feedback that can be incorporated when time permits based on priorities, schedule, resources etc: 1. Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood. 2. Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s. 3. Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. This is a requirement from a security perspective to not wait until the tpm TA is loaded to be able to extend the measurements into a tpm. I understand this can be done in the platform hook that calls tpm_record_measurement but it is convenient place to put tpm related platform hooks. 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something). Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Javier Almansa Sobrino via TF-A Sent: Friday, October 9, 2020 10:51 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Questions raised about Measured Boot + fTPM test case Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

5 years, 11 months

2
1
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Manish, I have been able to copy the test app (BL33) to entry point address 0x80020000. I confirmed from the Debugger that RAM address 0x80020000 is populated. I had to modify imx-atf makefile target to use the "-data" option as follows: flash_test_8: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -data App.bin 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin The -data option appears to copy the image at the 0x80020000 address. Now, I think we should be able to handoff since PC (program counter) is set : bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); I don't see any serial console output using an image that works when using u-boot. I am not using u-boot for certification reasons. Is there some way I can confirm that the handoff is happening from bl31.bin to the App.bin ? At which BL31 function or module does the handoff occur ? I don't see my HW breakpoint trigger at location location 0x80020000. Regards Ravi > On Oct 23, 2020, at 9:25 AM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Manish, > > Can you please point me to any example or a BL2 module which does the copy to RAM from Flash ? > Maybe I can try to copy the image to 0x80020000 before exiting BL31 from bl31_main(). > > The bl31.bin image boot fine on the target board (imx8qm) from location 0x80000000 > to start with. That copy to 0x80000000 must happen as well. I'm not sure where assuming > its some NXP firmware doing it. Do you know where it could be ? > > Regards > Ravi > > >> On Oct 23, 2020, at 4:46 AM, Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: >> >> Hi Ravi, >> >> This is normal behaviour when you RESET_TO_BL31. >> The loading of images (from flash to RAM) is part of BL2 code and in case of directly jumping to BL31, you need a mechanism to Load these images at proper location. >> Some platforms have a separate firmware which does this before starting execution of BL31, so that when BL31 hands over to BL33 it gets valid image there. >> >> thanks >> Manish >> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >> Sent: 23 October 2020 05:08 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: Re: [TF-A] BL31 as bootloader >> >> Hi Alexei, Manish, >> >> I repeated the test (below) a few times and see the same result. >> >> (1) Do I need to copy my BL33 (non-secure) image from >> flash.bin some how to RAM 0x80020000 entry point address ? >> Is there any example of how to copy the flash.bin image ? I not sure >> what address or where to copy it from. >> >> (2) Is there some existing debug code that I can use >> to dump/print the ARMv8 RAM address space from inside >> BL31.bin ? >> >> I only found some TF-A tf_log macros in debug.h. >> I would like to dump some memory address contents >> (like 0x80020000) from inside bl31.bin to console just for >> debugging at run-time. >> >>> On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: >>> >>> Hi Alexei, >>> >>> I captured the LOG_LEVEL=50 log (attached putty-ser0.log <https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. >>> I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) >>> >>> The flash.bin image I am running is constructed using imx-mkimage <https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: >>>> flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb >>> >>>> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin >>> >>> >>> I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. >>> >>> I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). >>>> diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c >>> >>>> index 92a2027dd..51afb13ea 100644 >>> >>>> --- a/bl31/bl31_main.c >>> >>>> >>> >>>> +++ b/bl31/bl31_main.c >>> >>>> @@ -147,6 +147,11 @@ void bl31_main(void) >>> >>>> * from BL31 >>> >>>> */ >>> >>>> bl31_plat_runtime_setup(); >>> >>>> + >>> >>>> + INFO("BL31: leaving bl31_main\n"); >>> >>>> + INFO("entering while(1)\n"); >>> >>>> + >>> >>>> + while (1) {}; >>> >>>> } >>> >>> It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at >>> address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). >>> See the debugger output <https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. >>> >>> When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin >>> copy the image from flash to RAM ? >>> >>> Can you suggest what could be going on ? >>> >>> Regards >>> Ravi >>> >>> >>> >>>> On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>> >>>> Hi Ravi, >>>> >>>> TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> >>>> >>>> You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. >>>> Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. >>>> >>>> Regards. >>>> Alexei >>>> >>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>>> Sent: 21 October 2020 19:59 >>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> Subject: Re: [TF-A] BL31 as bootloader >>>> >>>> Alexei, >>>> >>>> I don't have a DS-5 debugger setup/licensed. I am hoping >>>> on getting something shortly. >>>> >>>> Can you point me to the TFTF image that I can use to >>>> test the BL33 handoff ? >>>> >>>> Sorry, I'm not familiar at this time. >>>> >>>> Regards >>>> Ravi >>>> >>>> >>>>> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>>> >>>>> You can also use TFTF image as BL33. >>>>> >>>>> Alexei >>>>> >>>>> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>>>> Sent: 21 October 2020 15:26 >>>>> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>> Subject: Re: [TF-A] BL31 as bootloader >>>>> >>>>> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). >>>>> >>>>> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>>>> - You can use a linux image and device tree to test it >>>>> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function >>>>> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" >>>>> >>>>> >>>>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>>>> Sent: 21 October 2020 12:12 >>>>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>>>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>> Subject: Re: [TF-A] BL31 as bootloader >>>>> >>>>> Hi Alexei, Manish, >>>>> >>>>> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: >>>>>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, >>>>>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; >>>>>> #endif >>>>>> #endif >>>>>> + // DEBUG ONLY - FIXME >>>>>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>>>>> + >>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>>>>> >>>>>> /* init the first cluster's cci slave interface */ >>>>>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); >>>>>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); >>>>>> + >>>>>> } >>>>> But no luck. >>>>> >>>>> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? >>>>> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>>>>> >>>>> Thanks. >>>>> >>>>> >>>>>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>>>> >>>>>> Hi Ravi, >>>>>> >>>>>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: >>>>>> >>>>>> /* Populate entry point information for BL33 */ >>>>>> SET_PARAM_HEAD(&bl33_image_ep_info, >>>>>> PARAM_EP, >>>>>> VERSION_1, >>>>>> 0); >>>>>> /* >>>>>> * Tell BL31 where the non-trusted software image >>>>>> * is located and the entry state information >>>>>> */ >>>>>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); >>>>>> >>>>>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); >>>>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>>>>> >>>>>> Regards. >>>>>> Alexei >>>>>> >>>>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> Sent: 21 October 2020 10:57 >>>>>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>>>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> Subject: Re: [TF-A] BL31 as bootloader >>>>>> >>>>>> Hi Manish, >>>>>> >>>>>> The test image should not have any dependency on device tree (dtb?) >>>>>> for console init. >>>>>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match >>>>>> the MEK board. >>>>>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) >>>>>> as well but no luck. >>>>>> I don't believe PC is getting set to the 0x80020000 entry point. >>>>>> >>>>>> The test image has validated with u-boot using these tftpboot settings: >>>>>> setenv ipaddr x.x.x.x >>>>>> setenv serverip x.x.x.x >>>>>> tftpboot 0xf0000000 App.bin >>>>>> bootm 0xf0000000 >>>>>> >>>>>> I don't see any console output on the screen running it with bl31.bin as below. >>>>>> Is there any debug I can add somewhere to help troubleshoot? >>>>>> >>>>>> Can you please provide me instructions on where to patch this missing code : >>>>>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" >>>>>> I can try it to see if any change in behavior. >>>>>> >>>>>> Thanks in advance. >>>>>> Regards >>>>>> Ravi >>>>>> >>>>>> >>>>>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: >>>>>> > >>>>>> > Hi Ravi, >>>>>> > >>>>>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. >>>>>> > Also, does your "test image" depends on device tree for console initialization? >>>>>> > >>>>>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization >>>>>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>>>>> > >>>>>> > thanks >>>>>> > Manish >>>>>> > >>>>>> > ________________________________ >>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> > Sent: 21 October 2020 00:10 >>>>>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>>>>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> > Subject: Re: [TF-A] BL31 as bootloader >>>>>> > >>>>>> > Hi Alexei, >>>>>> > >>>>>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. >>>>>> > >>>>>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 >>>>>> > >>>>>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: >>>>>> > >>>>>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb >>>>>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin >>>>>> > >>>>>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). >>>>>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. >>>>>> > >>>>>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff >>>>>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff >>>>>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff >>>>>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff >>>>>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff >>>>>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff >>>>>> > NOTICE: Non-secure Partitioning Succeeded >>>>>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty >>>>>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 >>>>>> > INFO: bl31_platform_setup is called >>>>>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 >>>>>> > INFO: BL31: Initializing runtime services >>>>>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied >>>>>> > INFO: BL31: Preparing for EL3 exit to normal world >>>>>> > INFO: Entry point address = 0x80020000 >>>>>> > INFO: SPSR = 0x3c9 >>>>>> > INFO: BL31: DEBUG: image_type is: normal >>>>>> > >>>>>> > >>>>>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? >>>>>> > Note, the same test image works fine using u-boot. >>>>>> > >>>>>> > Regards >>>>>> > Ravi >>>>>> > >>>>>> > >>>>>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: >>>>>> > >>>>>> > Hi Alexei, >>>>>> > >>>>>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. >>>>>> > I will try it out and confirm. And, thanks for this suggestion. >>>>>> > >>>>>> > Regards >>>>>> > Ravi >>>>>> > >>>>>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>>>> > >>>>>> > Hi Ravi, >>>>>> > >>>>>> > Have you tried to use RESET_TO_BL31 build option for your platform? >>>>>> > >>>>>> > Regards. >>>>>> > Alexei >>>>>> > ________________________________ >>>>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> > Sent: 07 October 2020 17:01 >>>>>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>>>> > Subject: [TF-A] BL31 as bootloader >>>>>> > >>>>>> > Hi, >>>>>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. >>>>>> > >>>>>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. >>>>>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can >>>>>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. >>>>>> > This is without any security requirements or dependencies. >>>>>> > >>>>>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch >>>>>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point >>>>>> > 0x80020000 address ? >>>>>> > >>>>>> > Thanks in advance. >>>>>> > Ravi >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > TF-A mailing list >>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > TF-A mailing list >>>>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>>>> > >>>>>> > >>>>>> -- >>>>>> TF-A mailing list >>>>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>> >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 11 months

1
1
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, Manish, I repeated the test (below) a few times and see the same result. (1) Do I need to copy my BL33 (non-secure) image from flash.bin some how to RAM 0x80020000 entry point address ? Is there any example of how to copy the flash.bin image ? I not sure what address or where to copy it from. (2) Is there some existing debug code that I can use to dump/print the ARMv8 RAM address space from inside BL31.bin ? I only found some TF-A tf_log macros in debug.h. I would like to dump some memory address contents (like 0x80020000) from inside bl31.bin to console just for debugging at run-time. > On Oct 22, 2020, at 4:28 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, > > I captured the LOG_LEVEL=50 log (attached putty-ser0.log <https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. > I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) > > The flash.bin image I am running is constructed using imx-mkimage <https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: >> flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > >> ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > > > I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. > > I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). >> diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c > >> index 92a2027dd..51afb13ea 100644 > >> --- a/bl31/bl31_main.c > >> > >> +++ b/bl31/bl31_main.c > >> @@ -147,6 +147,11 @@ void bl31_main(void) > >> * from BL31 > >> */ > >> bl31_plat_runtime_setup(); > >> + > >> + INFO("BL31: leaving bl31_main\n"); > >> + INFO("entering while(1)\n"); > >> + > >> + while (1) {}; > >> } > > It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at > address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). > See the debugger output <https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. > > When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin > copy the image from flash to RAM ? > > Can you suggest what could be going on ? > > Regards > Ravi > > > >> On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >> >> Hi Ravi, >> >> TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> >> >> You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. >> Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. >> >> Regards. >> Alexei >> >> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >> Sent: 21 October 2020 19:59 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: Re: [TF-A] BL31 as bootloader >> >> Alexei, >> >> I don't have a DS-5 debugger setup/licensed. I am hoping >> on getting something shortly. >> >> Can you point me to the TFTF image that I can use to >> test the BL33 handoff ? >> >> Sorry, I'm not familiar at this time. >> >> Regards >> Ravi >> >> >>> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>> >>> You can also use TFTF image as BL33. >>> >>> Alexei >>> >>> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>> Sent: 21 October 2020 15:26 >>> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> Subject: Re: [TF-A] BL31 as bootloader >>> >>> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). >>> >>> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>> - You can use a linux image and device tree to test it >>> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function >>> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" >>> >>> >>> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>> Sent: 21 October 2020 12:12 >>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >>> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> Subject: Re: [TF-A] BL31 as bootloader >>> >>> Hi Alexei, Manish, >>> >>> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: >>>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, >>>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; >>>> #endif >>>> #endif >>>> + // DEBUG ONLY - FIXME >>>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>>> + >>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>>> >>>> /* init the first cluster's cci slave interface */ >>>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); >>>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); >>>> + >>>> } >>> But no luck. >>> >>> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? >>> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>>> >>> Thanks. >>> >>> >>>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>> >>>> Hi Ravi, >>>> >>>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: >>>> >>>> /* Populate entry point information for BL33 */ >>>> SET_PARAM_HEAD(&bl33_image_ep_info, >>>> PARAM_EP, >>>> VERSION_1, >>>> 0); >>>> /* >>>> * Tell BL31 where the non-trusted software image >>>> * is located and the entry state information >>>> */ >>>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); >>>> >>>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); >>>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>>> >>>> Regards. >>>> Alexei >>>> >>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> Sent: 21 October 2020 10:57 >>>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> Subject: Re: [TF-A] BL31 as bootloader >>>> >>>> Hi Manish, >>>> >>>> The test image should not have any dependency on device tree (dtb?) >>>> for console init. >>>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match >>>> the MEK board. >>>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) >>>> as well but no luck. >>>> I don't believe PC is getting set to the 0x80020000 entry point. >>>> >>>> The test image has validated with u-boot using these tftpboot settings: >>>> setenv ipaddr x.x.x.x >>>> setenv serverip x.x.x.x >>>> tftpboot 0xf0000000 App.bin >>>> bootm 0xf0000000 >>>> >>>> I don't see any console output on the screen running it with bl31.bin as below. >>>> Is there any debug I can add somewhere to help troubleshoot? >>>> >>>> Can you please provide me instructions on where to patch this missing code : >>>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" >>>> I can try it to see if any change in behavior. >>>> >>>> Thanks in advance. >>>> Regards >>>> Ravi >>>> >>>> >>>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: >>>> > >>>> > Hi Ravi, >>>> > >>>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. >>>> > Also, does your "test image" depends on device tree for console initialization? >>>> > >>>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization >>>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>>> > >>>> > thanks >>>> > Manish >>>> > >>>> > ________________________________ >>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> > Sent: 21 October 2020 00:10 >>>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> > Subject: Re: [TF-A] BL31 as bootloader >>>> > >>>> > Hi Alexei, >>>> > >>>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. >>>> > >>>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 >>>> > >>>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: >>>> > >>>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb >>>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin >>>> > >>>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). >>>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. >>>> > >>>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff >>>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff >>>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff >>>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff >>>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff >>>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff >>>> > NOTICE: Non-secure Partitioning Succeeded >>>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty >>>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 >>>> > INFO: bl31_platform_setup is called >>>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 >>>> > INFO: BL31: Initializing runtime services >>>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied >>>> > INFO: BL31: Preparing for EL3 exit to normal world >>>> > INFO: Entry point address = 0x80020000 >>>> > INFO: SPSR = 0x3c9 >>>> > INFO: BL31: DEBUG: image_type is: normal >>>> > >>>> > >>>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? >>>> > Note, the same test image works fine using u-boot. >>>> > >>>> > Regards >>>> > Ravi >>>> > >>>> > >>>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: >>>> > >>>> > Hi Alexei, >>>> > >>>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. >>>> > I will try it out and confirm. And, thanks for this suggestion. >>>> > >>>> > Regards >>>> > Ravi >>>> > >>>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>>> > >>>> > Hi Ravi, >>>> > >>>> > Have you tried to use RESET_TO_BL31 build option for your platform? >>>> > >>>> > Regards. >>>> > Alexei >>>> > ________________________________ >>>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> > Sent: 07 October 2020 17:01 >>>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>>> > Subject: [TF-A] BL31 as bootloader >>>> > >>>> > Hi, >>>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. >>>> > >>>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. >>>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can >>>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. >>>> > This is without any security requirements or dependencies. >>>> > >>>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch >>>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point >>>> > 0x80020000 address ? >>>> > >>>> > Thanks in advance. >>>> > Ravi >>>> > >>>> > >>>> > >>>> > -- >>>> > TF-A mailing list >>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>> > >>>> > >>>> > -- >>>> > TF-A mailing list >>>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>> > >>>> > >>>> -- >>>> TF-A mailing list >>>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 12 months

2
2
0 0

Fwd: BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, I captured the LOG_LEVEL=50 log (attached putty-ser0.log <https://www.dropbox.com/s/bi3hngmljksxl3a/putty-ser0.log?dl=0>) from TF-A bl31.bin. I see bl31 boots normally but never hands off to the BL33 normal world image (App.bin) The flash.bin image I am running is constructed using imx-mkimage <https://source.codeaurora.org/external/imx/imx-mkimage/tree/README?h=imx_4.…> tool with the following target: > flash_test_7: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin App.bin imx8qm-mek-ca53.dtb > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -p3 -ap App.bin a53 0x80020000 -data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin I used UUU tool to flash eMMC with flash.bin on the imx8QM MEK board. I inspected RAM using a trace32 debugger SW after using a while (1) to halt the execution at the end of bl31.bin main function (bl31_main()). > diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c > index 92a2027dd..51afb13ea 100644 > --- a/bl31/bl31_main.c > > +++ b/bl31/bl31_main.c > @@ -147,6 +147,11 @@ void bl31_main(void) > * from BL31 > */ > bl31_plat_runtime_setup(); > + > + INFO("BL31: leaving bl31_main\n"); > + INFO("entering while(1)\n"); > + > + while (1) {}; > } It appears that there's no data or image at 0x80020000 just before exiting bl31_main(). See the debugger RAM dump at address 0x80000000 (bl31.bin entry point) and 0x80020000 (BL33 or App.bin normal world app entry point). See the debugger output <https://www.dropbox.com/s/revv4qev2ky5djj/ksnip_20201022-153339.png?dl=0>. When should the flash image provided in flash.bin get copied to the RAM entry point 0x80020000 ? Should bl31.bin copy the image from flash to RAM ? Can you suggest what could be going on ? Regards Ravi > On Oct 22, 2020, at 6:15 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: > > Hi Ravi, > > TFTF image can be built from https://git.trustedfirmware.org/TF-A/tf-a-tests.git <https://git.trustedfirmware.org/TF-A/tf-a-tests.git> > > You can also try to increase TF-A log level by setting LOG_LEVEL=50 and check if BL33 memory region is mapped correctly. > Before passing control to BL33 and could add code to dump initial memory at BL33 start address to see if the image was loaded with no issues. > > Regards. > Alexei > > From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> > Sent: 21 October 2020 19:59 > To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> > Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> > Subject: Re: [TF-A] BL31 as bootloader > > Alexei, > > I don't have a DS-5 debugger setup/licensed. I am hoping > on getting something shortly. > > Can you point me to the TFTF image that I can use to > test the BL33 handoff ? > > Sorry, I'm not familiar at this time. > > Regards > Ravi > > >> On Oct 21, 2020, at 12:35 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >> >> You can also use TFTF image as BL33. >> >> Alexei >> >> From: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >> Sent: 21 October 2020 15:26 >> To: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>>; Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: Re: [TF-A] BL31 as bootloader >> >> The best way to figure out whether handing off to BL33 happened or not is by attaching a debugger(DS-5). >> >> is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >> - You can use a linux image and device tree to test it >> Refer to plat/brcm/common/brcm_bl31_setup.c -> "brcm_bl31_early_platform_setup()" function >> For linux as BL33 payload please use coder under "ARM_LINUX_KERNEL_AS_BL33" >> >> >> From: rkohli2000 gmail <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >> Sent: 21 October 2020 12:12 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> >> Cc: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>>; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: Re: [TF-A] BL31 as bootloader >> >> Hi Alexei, Manish, >> >> I tried the following patch to plat/imx/imx8qm/imx8qm_bl31_setup.c: >>> @@ -483,11 +486,15 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1, >>> bl32_image_ep_info.args.arg3 = BL32_FDT_OVERLAY_ADDR; >>> #endif >>> #endif >>> + // DEBUG ONLY - FIXME >>> + SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>> + >>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>> >>> /* init the first cluster's cci slave interface */ >>> cci_init(PLAT_CCI_BASE, imx8qm_cci_map, PLATFORM_CLUSTER_COUNT); >>> cci_enable_snoop_dvm_reqs(MPIDR_AFFLVL1_VAL(read_mpidr_el1())); >>> + >>> } >> But no luck. >> >> Is there some way to confirm my bl31.bin is handing off to any BL33 (normal world) test image ? >> In other words, is there any other A53 (or A72) test image (hello world like) I can validate with to further debug ? >>> >> Thanks. >> >> >>> On Oct 21, 2020, at 6:10 AM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>> >>> Hi Ravi, >>> >>> You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: >>> >>> /* Populate entry point information for BL33 */ >>> SET_PARAM_HEAD(&bl33_image_ep_info, >>> PARAM_EP, >>> VERSION_1, >>> 0); >>> /* >>> * Tell BL31 where the non-trusted software image >>> * is located and the entry state information >>> */ >>> bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); >>> >>> bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); >>> SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); >>> >>> Regards. >>> Alexei >>> >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> Sent: 21 October 2020 10:57 >>> To: Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> >>> Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> Subject: Re: [TF-A] BL31 as bootloader >>> >>> Hi Manish, >>> >>> The test image should not have any dependency on device tree (dtb?) >>> for console init. >>> I used the NXP provided imx8qm-mek-ca53.dtb file which should match >>> the MEK board. >>> I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) >>> as well but no luck. >>> I don't believe PC is getting set to the 0x80020000 entry point. >>> >>> The test image has validated with u-boot using these tftpboot settings: >>> setenv ipaddr x.x.x.x >>> setenv serverip x.x.x.x >>> tftpboot 0xf0000000 App.bin >>> bootm 0xf0000000 >>> >>> I don't see any console output on the screen running it with bl31.bin as below. >>> Is there any debug I can add somewhere to help troubleshoot? >>> >>> Can you please provide me instructions on where to patch this missing code : >>> "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" >>> I can try it to see if any change in behavior. >>> >>> Thanks in advance. >>> Regards >>> Ravi >>> >>> >>> On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com <mailto:Manish.Pandey2@arm.com>> wrote: >>> > >>> > Hi Ravi, >>> > >>> > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. >>> > Also, does your "test image" depends on device tree for console initialization? >>> > >>> > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization >>> > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); >>> > >>> > thanks >>> > Manish >>> > >>> > ________________________________ >>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> > Sent: 21 October 2020 00:10 >>> > To: Ravi Kohli <rkohli2000(a)gmail.com <mailto:rkohli2000@gmail.com>> >>> > Cc: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> > Subject: Re: [TF-A] BL31 as bootloader >>> > >>> > Hi Alexei, >>> > >>> > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. >>> > >>> > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 >>> > >>> > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: >>> > >>> > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb >>> > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin >>> > >>> > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). >>> > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. >>> > >>> > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff >>> > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff >>> > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff >>> > NOTICE: Memreg 6 0x80000000 -- 0xffffffff >>> > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff >>> > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff >>> > NOTICE: Non-secure Partitioning Succeeded >>> > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty >>> > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 >>> > INFO: bl31_platform_setup is called >>> > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 >>> > INFO: BL31: Initializing runtime services >>> > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied >>> > INFO: BL31: Preparing for EL3 exit to normal world >>> > INFO: Entry point address = 0x80020000 >>> > INFO: SPSR = 0x3c9 >>> > INFO: BL31: DEBUG: image_type is: normal >>> > >>> > >>> > Can anyone please suggest what could be the issue here that I don't see the test image console output ? >>> > Note, the same test image works fine using u-boot. >>> > >>> > Regards >>> > Ravi >>> > >>> > >>> > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> wrote: >>> > >>> > Hi Alexei, >>> > >>> > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. >>> > I will try it out and confirm. And, thanks for this suggestion. >>> > >>> > Regards >>> > Ravi >>> > >>> > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >>> > >>> > Hi Ravi, >>> > >>> > Have you tried to use RESET_TO_BL31 build option for your platform? >>> > >>> > Regards. >>> > Alexei >>> > ________________________________ >>> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> > Sent: 07 October 2020 17:01 >>> > To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >>> > Subject: [TF-A] BL31 as bootloader >>> > >>> > Hi, >>> > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. >>> > >>> > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. >>> > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can >>> > specify this container image with both bl31.bin and a separate custom app at a give flash address. >>> > This is without any security requirements or dependencies. >>> > >>> > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch >>> > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point >>> > 0x80020000 address ? >>> > >>> > Thanks in advance. >>> > Ravi >>> > >>> > >>> > >>> > -- >>> > TF-A mailing list >>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>> > >>> > >>> > -- >>> > TF-A mailing list >>> > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>> > >>> > >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a>

5 years, 12 months

1
0
0 0

Re: [TF-A] BL31 as bootloader

by Alexei Fedorov

Hi Ravi, You can take a look at arm_bl31_early_platform_setup() in plat\arm\common\arm_bl31_setup.c: /* Populate entry point information for BL33 */ SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); /* * Tell BL31 where the non-trusted software image * is located and the entry state information */ bl33_image_ep_info.pc = plat_get_ns_image_entrypoint(); bl33_image_ep_info.spsr = arm_get_spsr_for_bl33_entry(); SET_SECURITY_STATE(bl33_image_ep_info.h.attr, NON_SECURE); Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 21 October 2020 10:57 To: Manish Pandey2 <Manish.Pandey2(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] BL31 as bootloader Hi Manish, The test image should not have any dependency on device tree (dtb?) for console init. I used the NXP provided imx8qm-mek-ca53.dtb file which should match the MEK board. I have tested removing "--data imx8qm-mek-ca53.dtb 0x83000000" (below) as well but no luck. I don't believe PC is getting set to the 0x80020000 entry point. The test image has validated with u-boot using these tftpboot settings: setenv ipaddr x.x.x.x setenv serverip x.x.x.x tftpboot 0xf0000000 App.bin bootm 0xf0000000 I don't see any console output on the screen running it with bl31.bin as below. Is there any debug I can add somewhere to help troubleshoot? Can you please provide me instructions on where to patch this missing code : "SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0);" I can try it to see if any change in behavior. Thanks in advance. Regards Ravi On Wed, Oct 21, 2020 at 5:15 AM Manish Pandey2 <Manish.Pandey2(a)arm.com> wrote: > > Hi Ravi, > > Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. > Also, does your "test image" depends on device tree for console initialization? > > One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization > SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); > > thanks > Manish > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 21 October 2020 00:10 > To: Ravi Kohli <rkohli2000(a)gmail.com> > Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] BL31 as bootloader > > Hi Alexei, > > I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. > > make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 > > I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: > > flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb > ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin > > Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). > I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. > > NOTICE: Memreg 3 0x38000000 -- 0x3bffffff > NOTICE: Memreg 4 0x60000000 -- 0x6fffffff > NOTICE: Memreg 5 0x70000000 -- 0x7fffffff > NOTICE: Memreg 6 0x80000000 -- 0xffffffff > NOTICE: Memreg 7 0x400000000 -- 0x43fffffff > NOTICE: Memreg 8 0x880000000 -- 0x97fffffff > NOTICE: Non-secure Partitioning Succeeded > NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty > NOTICE: BL31: Built : 17:33:32, Oct 20 2020 > INFO: bl31_platform_setup is called > INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x80020000 > INFO: SPSR = 0x3c9 > INFO: BL31: DEBUG: image_type is: normal > > > Can anyone please suggest what could be the issue here that I don't see the test image console output ? > Note, the same test image works fine using u-boot. > > Regards > Ravi > > > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, > > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > I will try it out and confirm. And, thanks for this suggestion. > > Regards > Ravi > > On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com> wrote: > > Hi Ravi, > > Have you tried to use RESET_TO_BL31 build option for your platform? > > Regards. > Alexei > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 07 October 2020 17:01 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] BL31 as bootloader > > Hi, > I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. > > I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. > I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can > specify this container image with both bl31.bin and a separate custom app at a give flash address. > This is without any security requirements or dependencies. > > Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch > a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point > 0x80020000 address ? > > Thanks in advance. > Ravi > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 12 months

3
6
0 0

Re: [TF-A] BL31 as bootloader

by Manish Pandey2

Hi Ravi, Can you please confirm if control reached "test image" ? I guess, yes, as PC has right value. Also, does your "test image" depends on device tree for console initialization? One thing i see missing in "plat/imx/imx8qm/imx8qm_bl31_setup.c +352" is bl33 header initialization SET_PARAM_HEAD(&bl33_image_ep_info, PARAM_EP, VERSION_1, 0); thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 21 October 2020 00:10 To: Ravi Kohli <rkohli2000(a)gmail.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] BL31 as bootloader Hi Alexei, I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. NOTICE: Memreg 3 0x38000000 -- 0x3bffffff NOTICE: Memreg 4 0x60000000 -- 0x6fffffff NOTICE: Memreg 5 0x70000000 -- 0x7fffffff NOTICE: Memreg 6 0x80000000 -- 0xffffffff NOTICE: Memreg 7 0x400000000 -- 0x43fffffff NOTICE: Memreg 8 0x880000000 -- 0x97fffffff NOTICE: Non-secure Partitioning Succeeded NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty NOTICE: BL31: Built : 17:33:32, Oct 20 2020 INFO: bl31_platform_setup is called INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x80020000 INFO: SPSR = 0x3c9 INFO: BL31: DEBUG: image_type is: normal Can anyone please suggest what could be the issue here that I don't see the test image console output ? Note, the same test image works fine using u-boot. Regards Ravi On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Alexei, Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. I will try it out and confirm. And, thanks for this suggestion. Regards Ravi On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com<mailto:Alexei.Fedorov@arm.com>> wrote: Hi Ravi, Have you tried to use RESET_TO_BL31 build option for your platform? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 07 October 2020 17:01 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] BL31 as bootloader Hi, I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can specify this container image with both bl31.bin and a separate custom app at a give flash address. This is without any security requirements or dependencies. Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point 0x80020000 address ? Thanks in advance. Ravi -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- 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, 12 months

2
1
0 0

Re: [TF-A] BL31 as bootloader

by rkohli2000 gmail

Hi Alexei, I built my TF-A (imx-atf) b31.bin image using the RESET_TO_BL31 build option for the i.MX8QM MEK dev kit. make DEBUG=1 RESET_TO_BL31=1 PLAT=imx8qm bl31 I used the imx-mkimage tool to generate a flash.bin (flash bootable image) with the following target to run on the MEK: flash_cortex_a53: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin bl31.bin MyA53Serial.bin imx8qm-mek-ca53.dtb ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c flags 0x00200000 -scfw scfw_tcm.bin -ap bl31.bin a53 0x80000000 -c -p3 -ap MyA53Serial.bin a53 0x80020000 -p4 --data imx8qm-mek-ca53.dtb 0x83000000 -out flash.bin Here, I allocated bl31.bin to boot from 0x80000000 and a test image at BL33 (normal world) entry point 0x80020000 (both for Cortex-A53). I can see DEBUG console output from the bl31.bin image but no serial output from my test image I am trying to boot from 0x80020000. NOTICE: Memreg 3 0x38000000 -- 0x3bffffff NOTICE: Memreg 4 0x60000000 -- 0x6fffffff NOTICE: Memreg 5 0x70000000 -- 0x7fffffff NOTICE: Memreg 6 0x80000000 -- 0xffffffff NOTICE: Memreg 7 0x400000000 -- 0x43fffffff NOTICE: Memreg 8 0x880000000 -- 0x97fffffff NOTICE: Non-secure Partitioning Succeeded NOTICE: BL31: v2.2(debug):imx_5.4.24_er3-1-g06450210f-dirty NOTICE: BL31: Built : 17:33:32, Oct 20 2020 INFO: bl31_platform_setup is called INFO: GICv3 with legacy support detected. ARM GICv3 driver initialized in EL3 INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x80020000 INFO: SPSR = 0x3c9 INFO: BL31: DEBUG: image_type is: normal Can anyone please suggest what could be the issue here that I don't see the test image console output ? Note, the same test image works fine using u-boot. Regards Ravi > On Oct 7, 2020, at 12:43 PM, rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Alexei, > > Thanks for your reply. I have not verified the RESET_TO_BL1 for imx8qm yet. > I will try it out and confirm. And, thanks for this suggestion. > > Regards > Ravi > >> On Oct 7, 2020, at 12:12 PM, Alexei Fedorov <Alexei.Fedorov(a)arm.com <mailto:Alexei.Fedorov@arm.com>> wrote: >> >> Hi Ravi, >> >> Have you tried to use RESET_TO_BL31 build option for your platform? >> >> Regards. >> Alexei >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org <mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Sent: 07 October 2020 17:01 >> To: tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>> >> Subject: [TF-A] BL31 as bootloader >> >> Hi, >> I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. >> >> I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. >> I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can >> specify this container image with both bl31.bin and a separate custom app at a give flash address. >> This is without any security requirements or dependencies. >> >> Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch >> a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point >> 0x80020000 address ? >> >> Thanks in advance. >> Ravi >> >> >> >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 12 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 22nd October 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 22nd October 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Encrypted FIP Support * Presented by Sumit Garg * Summary * Overview of FIP encryption. * Common challenges with firmware encryption implementation and how we addressed those in TF-A. * FIP encryption implementation details. * Follow on Measured Boot Support in TF-A discussion from last meeting (if required) * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

5 years, 12 months

1
0
0 0

Re: [TF-A] TF-A Tech Forum Agenda @ Thr 8th October 2020 16:00-1700 BST

by Ruchika Gupta

Hi Joanna, Can you please share the presentation of the session on Measured Boot. It is not currently available on the webpage - https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Regards, Ruchika On Tue, 6 Oct 2020 at 22:58, Joanna Farley via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > The next TF-A Tech Forum is scheduled for Thu 8th October 2020 16:00 – > 17:00 (BST). A reoccurring meeting invite has been sent out to the > subscribers of this TF-A mailing list. If you don’t have this please let me > know. > > > > Agenda: > > > > - Measured Boot Support in TF-A > - Presented by Alexei Fedorov and Javier Almansa Sobrino > - Update on the support for Measured Boot in TF-A along with an > overview of test cases for integration with a TPM service > - Optional TF-A Mailing List Topic Discussions > > > > If TF-A contributors have anything they wish to present at any future TF-A > tech forum please contact me to have that scheduled. > > > > Previous sessions, both recording and presentation material can be found > on the trustedfirmware.org TF-A Technical meeting webpage: > https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ > > > > A scheduling tracking page is also available to help track sessions > suggested and being prepared: > https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final > decisions on what will be presented will be shared a few days before the > next meeting and shared on the TF-A mailing list. > > > > Thanks > > > > Joanna > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

6 years

2
1
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

Hi All, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days. Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community * Constant-time code * How to be an effective Mbed TLS reviewer * Processes - how does work get scheduled? * Roadmap, Mbed TLS3.0 * PSA Crypto APIs * How Do I contribute my first review. Thanks, Shebu (TrustedFirmware.org Co-Chair, Mbed TLS Technology Manager) * https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

6 years

1
0
0 0

commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Biju Das

Hi All, I am porting Renesas RZ/G2M[1] platform to TF-A Master branch(commitid: eeb77da646844) . Initially faced a compilation error [2] which is fixed by using "#define" instead of "static const uint64_t". Then on target, found that BL31 is failed to boot[3], which is fixed by reverting the commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes"), see the logs [3]. Q1) Have you seen this issue? Please share your thoughts on this issues. [1] https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz/… [2] https://lists.trustedfirmware.org/pipermail/tf-a/2020-October/000763.html [3] Failure logs ------------ NOTICE: BL2: RZ/G Initial Program Loader(CA57) Rev.2.0.6 NOTICE: BL2: PRR is RZG G2M Ver.1.3 NOTICE: BL2: Board is HiHope RZ/G2M Rev.4.0 NOTICE: BL2: Boot device is QSPI Flash(40MHz) NOTICE: BL2: LCM state is unknown NOTICE: BL2: DDR3200(rev.0.40) NOTICE: BL2: [COLD_BOOT] NOTICE: BL2: DRAM Split is 2ch NOTICE: BL2: QoS is default setting(rev.0.19) NOTICE: BL2: DRAM refresh interval 1.95 usec NOTICE: BL2: Periodic Write DQ Training NOTICE: BL2: CH0: 400000000 - 47fffffff, 2 GiB NOTICE: BL2: CH2: 600000000 - 67fffffff, 2 GiB NOTICE: BL2: FDT at 0xe632a648 NOTICE: BL2: v2.3(release):v2.3-778-g4fd58b045 NOTICE: BL2: Built : 18:14:35, Oct 8 2020 NOTICE: BL2: Normal boot NOTICE: BL2: dst=0xe6328300 src=0x8180000 len=512(0x200) NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) NOTICE: rcar_file_len: len: 0x0003e000 NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=253952(0x3e000) NOTICE: rcar_file_len: len: 0x00100000 NOTICE: BL2: dst=0x50000000 src=0x8300000 len=1048576(0x100000) NOTICE: BL2: Booting BL31 [4]Working logs after reverting the commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") -------------------------------------- NOTICE: BL2: RZ/G Initial Program Loader(CA57) Rev.2.0.6 NOTICE: BL2: PRR is RZG G2M Ver.1.3 NOTICE: BL2: Board is HiHope RZ/G2M Rev.4.0 NOTICE: BL2: Boot device is QSPI Flash(40MHz) NOTICE: BL2: LCM state is unknown NOTICE: BL2: DDR3200(rev.0.40) NOTICE: BL2: [COLD_BOOT] NOTICE: BL2: DRAM Split is 2ch NOTICE: BL2: QoS is default setting(rev.0.19) NOTICE: BL2: DRAM refresh interval 1.95 usec NOTICE: BL2: Periodic Write DQ Training NOTICE: BL2: CH0: 400000000 - 47fffffff, 2 GiB NOTICE: BL2: CH2: 600000000 - 67fffffff, 2 GiB NOTICE: BL2: FDT at 0xe632a648 NOTICE: BL2: v2.3(release):v2.3-779-geba02ef39 NOTICE: BL2: Built : 18:16:47, Oct 8 2020 NOTICE: BL2: Normal boot NOTICE: BL2: dst=0xe6328300 src=0x8180000 len=512(0x200) NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) NOTICE: rcar_file_len: len: 0x0003e000 NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=253952(0x3e000) NOTICE: rcar_file_len: len: 0x00100000 NOTICE: BL2: dst=0x50000000 src=0x8300000 len=1048576(0x100000) NOTICE: BL2: Booting BL31 U-Boot 2020.10-00535-gd0e9210a2f (Oct 08 2020 - 12:34:09 +0100) CPU: Renesas Electronics R8A774A1 rev 1.3 Model: HopeRun HiHope RZ/G2M with sub board DRAM: 3.9 GiB MMC: mmc@ee100000: 0, mmc@ee160000: 1 Loading Environment from MMC... OK In: serial@e6e88000 Out: serial@e6e88000 Err: serial@e6e88000 Net: eth0: ethernet@e6800000 Hit any key to stop autoboot: 0 Regards, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

6 years

2
20
0 0

Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Ash Wilding

Hi Biju, Andre, > sctlr_el3 = 0x0000000030c5183a The MMU is still disabled since we're so early in BL31, so nothing preventing us from making an actual access to physical address 0x0. As Andre already noted: > x30 = 0x0000000000000000 > elr_el3 = 0x0000000000000000 > far_el3 = 0x0000000000000000 It looks like we do have an errant null pointer dereference here. If I had to guess, the I-side successfully fetches a 32-bit word from physical address 0x0, but then fails to decode that bit pattern as a valid opcode. This is reported as "unknown reason", like you're seeing: <quote Arm ARM DDI 0487E.a pp D13-2963> This EC code is used for all exceptions that are not covered by any other EC value. This includes exceptions that are generated in the following situations: - ... - Instruction encodings that are unallocated. - ... </quote> Hope that helps, Ash.

6 years

2
1
0 0

Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Ash Wilding

From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Ash Wilding via TF-A <TF-A(a)lists.trustedfirmware.org> Date: Sunday, 11 October 2020 at 18:53 <...> It looks like we do have an errant null pointer dereference here. <...> Just to clarify, when I say "null pointer dereference": - you may be trampling over your stack, causing you to pop 0x0 into LR and return there; - you may be trampling over your stack, causing you to pop 0x0 into a GPR that is then BLR'd to; - you may be trampling over some other region of memory containing a function pointer, causing you to load 0x0 into a GPR that is then BLR'd to; - etc. Cheers, Ash.

6 years

1
0
0 0

Questions raised about Measured Boot + fTPM test case

by Javier Almansa Sobrino

Hello all, Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB. The modules involved on the interaction with the fTPM (for this particular example) are: * optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world). * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case. In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM. I would also like to highlight the following points: A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS. B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually. Please, let me know in case you have any more questions. Best regards, Javier

6 years

1
0
0 0

Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms.

by Alexei Fedorov

Hi Biju, As you work with Renesas platforms, have you also seen "Renesas rcar-gen3: cert_header_sa6 Compilation Issue" which I reported on the mailing list on 10/12/2018 and is still not fixed? tools\renesas\rcar_layout_create\sa6.c has #include <stdint.h> which causes compilation error on Yocto 3.13: | aarch64-poky-linux-gcc -DRCAR_SA0_SIZE=1 -DRCAR_SA6_TYPE=0 -I../../include/lib/stdlib -D=AARCH64 -c -o sa6.o sa6.c | In file included from sa6.c:7:0: | /home/alexei/Work/Yocto_3.13_20181205/build/tmp/work/h3ulcb-poky-linux/arm-tf/2.0+gitAUTOINC+19b56cf4a2_556d7d9e3b-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory | # include_next <stdint.h> | ^~~~~~~~~~ | compilation terminated. | <builtin>: recipe for target 'sa6.o' failed | make[1]: *** [sa6.o] Error 1 | plat/renesas/rcar/platform.mk:403: recipe for target 'rcar_layout_tool' failed | make: *** [rcar_layout_tool] Error 2 | ERROR: oe_runmake failed There's no compilation error with gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf tool chain, because compiler searches for <stdint.h> in \gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf\lib\gcc\aarch64-elf\8.2.1\include finding "stdint.h" with # include_next <stdint.h> and then getting "stdint.h" from gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf\aarch64-elf\include folder. Trusted Firmware-A Porting Guide reads that "To avoid subtle toolchain behavioral dependencies, the header files provided by the compiler are not used. The software is built with the ``-nostdinc`` flag to ensure no headers are included from the toolchain inadvertently. ", tools\renesas\rcar_layout_create\makefile has flags defined as: CFLAGS += ${DEFINES} CFLAGS += -I../../include/lib/stdlib and adding "-nostdinc" flag will make gcc-arm-8.2-2018.08-i686-mingw32-aarch64-elf compilation fail because ../../include/lib/stdlib is a wrong path (taken from Renesas ARM-TF version 1.5 "tools\dummy_create\makefile") to include\lib\libc\stdint.h for version ARM-TF version 2.0. This issue can be fixed by changing CFLAGS to CFLAGS += -nostdinc \ -I../../../include/lib/libc \ -I../../../include/lib/libc/aarch64 Regards. Alexei. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Biju Das via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 09 October 2020 08:12 To: Andre Przywara <Andre.Przywara(a)arm.com>; TF-A(a)lists.trustedfirmware.org <TF-A(a)lists.trustedfirmware.org>; Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com>; Joanna Farley <Joanna.Farley(a)arm.com> Cc: Marek Vasut <marek.vasut(a)gmail.com>; Chris Paterson <Chris.Paterson2(a)renesas.com>; Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Subject: Re: [TF-A] commit 75fab6496e5fce9a11 ("libc: memset: improve performance by avoiding single byte writes") causing BL31 boot failure on Renesas RZ/G2 platforms. Hi Andre, Thanks for the feedback. > Subject: Re: commit 75fab6496e5fce9a11 ("libc: memset: improve > performance by avoiding single byte writes") causing BL31 boot failure on > Renesas RZ/G2 platforms. > > On 08/10/2020 20:05, Biju Das wrote: > > Hi, > > > I am porting Renesas RZ/G2M[1] platform to TF-A Master > > branch(commitid: eeb77da646844) . Initially faced a compilation error [2] > which is fixed by using "#define" instead of "static const uint64_t". > > What is your exact fix? That compilation error sounds like a more serious > issue, I am scratching my head how such a change would really fix things? Looks like this issue is related to toolchain, I was using aarch64-linux-gcc-7 on U-buntu 18.04 Host toolchain. The compilation is error is fixed by the below changes. #define BL31_RO_BASE BL_CODE_BASE #define BL31_RO_LIMIT BL_CODE_END #define BL31_COHERENT_RAM_BASE BL_COHERENT_RAM_BASE #define BL31_COHERENT_RAM_LIMIT BL_COHERENT_RAM_END The warning fix should not lead to compilation error with the old toolchains. It should be backward compatible to the old toolchains right? Please share your views. > And do you see this with mainline? I tried: Yes > $ make bl31 PLAT=rcar LSI=M3 MBEDTLS_DIR=../mbedtls.git on origin/master > and it built just fine. Thanks for the hint, After using the toolchain[1], I got the same results as your's. it compiles successfully. So the issue is related to using older tool chains. [1] https://developer.arm.com/tools-and-software/open-source-software/developer… > > > Then on target, found that BL31 is failed to boot[3], which is fixed > > by reverting the commit 75fab6496e5fce9a11 > > ("libc: memset: improve performance by avoiding single byte writes"), see > the logs [3]. > > Mmmh, interesting. Can you build with "DEBUG=1" to get more output from > BL31? Sure Will do and provide feedback. > I see some calls to memset() from code in drivers/renesas/rcar. > Can you add some debug prints at the top of memset() to dump the > parameters on each call? To see what breaks it? OK. > Are you using memset on some I/O memory, by any chance? And that > doesn't support all access types, like 64-bit stores? Will check and let you know. Cheers, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

2
2
0 0

Forthcoming Trusted Firmware-A 2.4 release

by Manish Badarkhe

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.4 release during the second week of November 2020 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.3 release. As part of this, a release candidate tag will be created and release activities will commence from Friday 30th Oct 2020 (code freeze date). Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any Pull Requests (PR’s) desired to make the 2.4 release are submitted in good time, to be completed by Tuesday 27th Oct 2020. Any major enhancement PR’s still open after that date will not be merged until after the release Please note, there is no guarantee that all patches under review will be merged before the code freeze date. Any patches that don’t make the code freeze date will complete their review and merge post the release date. Thanks Manish Badarkhe

6 years

1
0
0 0

Compilation error with commit "ca661a0092c8ead5ac7df57c55fffcc835d9c0b9"

by Biju Das

Hi All, I am getting compilation error with Mainline TFA on renesas platform for bl31 build. Build command: #make CROSS_COMPILE=aarch64-linux-gnu- bl31 PLAT=rcar LSI=M3 MBEDTLS_DIR=../mbedtls Q1) Have any one see this issue? Please correct me, if I am doing something wrong. On further investigation, the below commit introduced the issue [1] [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/plat/ren… It gives compilation error " error: initializer element is not constant" for BL_CODE_BASE [2] [2] https://elixir.bootlin.com/arm-trusted-firmware/latest/source/plat/renesas/… BL_CODE_BASE gets its value from linker in [3] [3] https://elixir.bootlin.com/arm-trusted-firmware/latest/source/include/commo… If you see [4], the initializer element is not constant [4] https://elixir.bootlin.com/arm-trusted-firmware/latest/source/include/lib/u… Error logs: biju@biju-VirtualBox:~/work/trusted-firmware-a$ CC plat/renesas/rcar/bl31_plat_setup.c plat/renesas/rcar/bl31_plat_setup.c:25:39: error: initializer element is not constant static const uint64_t BL31_RO_BASE = BL_CODE_BASE; ^~~~~~~~~~~~ plat/renesas/rcar/bl31_plat_setup.c:26:40: error: initializer element is not constant static const uint64_t BL31_RO_LIMIT = BL_CODE_END; ^~~~~~~~~~~ plat/renesas/rcar/bl31_plat_setup.c:29:48: error: initializer element is not constant static const uint64_t BL31_COHERENT_RAM_BASE = BL_COHERENT_RAM_BASE; ^~~~~~~~~~~~~~~~~~~~ plat/renesas/rcar/bl31_plat_setup.c:30:49: error: initializer element is not constant static const uint64_t BL31_COHERENT_RAM_LIMIT = BL_COHERENT_RAM_END; ^~~~~~~~~~~~~~~~~~~ Makefile:1109: recipe for target '/home/biju/work/trusted-firmware-a/build/rcar/release/bl31/bl31_plat_setup.o' failed make: *** [/home/biju/work/trusted-firmware-a/build/rcar/release/bl31/bl31_plat_setup.o] Error 1 Regards, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

6 years

1
1
0 0

Re: [TF-A] Query SPD/SPMD behavior with EHF

by Achin Gupta

Hi Sandeep, A few comments inline from a SW architecture/FF-A perspective. > On 5 Oct 2020, at 12:28, Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Olivier, > Appreciate the details. I have a different perception of G0 > interrupts and their relevance to RAS/ critical events. > Comments in line. > Thanks > Sandeep > > On Fri, Oct 2, 2020 at 6:47 PM Olivier Deprez <Olivier.Deprez(a)arm.com> wrote: >> >> Hi Sandeep, >> >> Here are a few more details. >> The reasoning differs when considering pre-Armv8.4 platforms (1) vs Armv8.4 platforms onwards with secure virtualization enabled (2). >> >> Case (1): >> >> EHF framework unifies EL3 exceptions delivered via different vectors and allows them to be handled in a common way. It is also allowing exception delegation handling to lower secure ELs. This framework although primarily used for RAS, is also used for SDEI and platform EL3 interrupts. EL3's role in this case is about trapping and routing the event to appropriate the component (when the interrupt/exception is not handled solely at EL3). >> >> The interoperability between EHF and a Trusted OS is not accurately defined apart from this guidance in EHF documentation: >> "In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, the dispatcher must adopt a model where Non-secure interrupts are received at EL3, but are then synchronously handled over to S-EL1." >> >> Until then for the specific RAS handling scenario, this was delegated to a StandaloneMM partition running at S-EL0 (through the SPM-MM implementation) and not necessarily delegated to a TOS. > > Reliability is provided by the feature of G0 interrupt that it can not > be masked by lower ELs. Such interrupt being handled at EL3 or being > delegated to other components does not impact the > reliable feature of G0 interrupt. Sure its handling must be offloaded > to other components to keep EL3 firmware light. But If it were just > about handling an interrupt then it could have been entirely handled > in each state without even requiring an EL3 interrupt type. Reliability in RAS is a different concept. RAS error interrupts do not provide reliability. They report unreliable operation. Routing RAS interrupts to EL3 is an implementation choice called Firmware First Handling (FFH). Indeed, the interrupts could be routed to a lower EL which is called Kernel first handling (KFH). For e.g. an implementation could decide to handle corrected errors Kernel first. Uncorrected errors could be routed to a platform controller instead of firmware or be routed to both. There is no single solution. With FFH, the main requirement is that an uncorrected error must be handled even if the Normal world is not in a position to do so. There are non-technical requirements too but lets not go there. So I don’t think there is a requirement that "no lower EL" should be able to mask the interrupt. EL3/S-EL1 and EL3/S-EL2 are at the same privilege level as far as access to the physical address space is concerned. G0 interrupts could be routed to EL3 but they can be disabled by S-EL1 or S-EL2 by programming the GIC distributor. The main point being that software in all privileged exception levels in the Secure world must be trusted to handle RAS errors in the Normal world. Routing G0 interrupts to EL3 is not a silver bullet. When support for FFH was added to TF-A, there was no use case to put software in S-EL1. This EL is owned by TF-A which deploys a simple shim layer. The EHF was developed with this assumption in mind. If your requirement is to put a Trusted OS in S-EL1 and continue doing RAS error handling, then the requirements of the Trusted OS w.r.t the interrupt routing model must be factored in. Hence, the question about what exactly are your requirements. I can understand the desire to reuse EHF but it cannot come at the cost of not meeting the TOS requirements. It needs a SW architecture discussion first. It might be possible to preempt S-EL1 and route RAS errors to EL3 in some cases. A cooperative model (2) between S-EL1 and EL3 (as Olivier described) is what most Trusted OSs implement today. It would be good to understand why that would not work for RAS. > >> >> In order to better help you, we would need more information on the scenario you intend to achieve, and the environment (Arm architecture version and extensions, GIC version). >> Or maybe your question was out of curiosity for the longer term approach (2) as described below? > > As per sbsa level III spec: sbsa non secure watchdog WS1 (reset) must > be targeted at EL3. The patch in review ref: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5495 > And we would want a watchdog interrupt to preempt all execution > context. I would expect the same with any RAS or SDEI critical prio > events. Thanks for pointing this out! SBSA applies to the Server segment. It was reasonable to assume that Secure firmware almost entirely resides in EL3. Hence the guidance. We will look at rewording this in a future release. The intent is that since it is a Non-secure Watchdog, the WS1 signal must not be masked by the Normal world. The BSA applies to all segments. It leaves routing of WS1 implementation defined as long as the Normal world cannot mask it. It could be routed to S-EL1 or S-EL2 if that fulfils the requirement. > Another misc application of our platform is to be able to forcefully > turn off/ halt/ just ping any core at any execution context (S/NS). > These motivated me to leverage EHF. But the idea of dropping EHF in > future designs makes me think now ! > > Our current system is pre Armv8.4. We will stick to case (1). Case > (2) ie SPMD was just my quoricity. However, I felt PSA-FFA may > replace TOS specific SPDs someday. > Making SPMD relevant in this discussion even with pre 8.4 systems. > Because at least the TOS will have to follow one policy. The SPMD is indeed meant to replace TOS specific SPDs. It is meant to cater for the RAS use case as well. From an FF-A perspective, a cooperative approach is simpler. I would like to understand why this would not work for RAS error interrupts as well. Reuse of EHF is an implementation level discussion and I don’t think that is off the table even with (2). > >> >> Case (2): >> >> As a general rule, it is preferred that EL3 reduces its footprint and minimises platform specific handling code. > > Agreed. Applies to case(1) aswell and heavy lifting to be delegated > to lower ELs in either security states. My concern is on 'Taking' the > interrupt handling (mjust)can be delegated. It would certainly be desirable to reuse the EHF. However, it is not possible to delegate the heavy lifting to preempted software in S-EL1 or S-EL2 without significantly increasing their complexity. This is not the current direction of travel of FF-A. > >> EHF framework would most probably not be enabled at all. >> The priority logic provided by the GIC PMR register to mask NS interrupts cannot really work as before because all of trusted EL3/S-EL2 and untrusted S-EL1 SPs can manipulate this register. > > This is a limitation. This can be taken care of by cooperative > software design. ie. S_EL2/S_EL1 will not set PMR out of its range. > And the platform defines what's EL3 priority range. > GIC_LOWEST_EL3_PRI. This falls under the solution space. It would be good to understand what is it you want to run on S-EL1/S-EL2 first. > >> Any secure/non-secure interrupt triggered while running SEL1/SEL0 is trapped first by the S-EL2 firmware (or the so-called SPMC). This translates into SCR_EL3.FIQ/IRQ=0 in the secure world. >> Group1NS interrupts are redirected to SPMD for routing to NWd. >> >> A Group0 interrupt is possibly redirected to a platform driver into an S-EL1 secure partition (e.g. a RAS handling service). >> Hence it does no longer hold true that Group0 interrupts are necessarily qualified as "EL3 interrupts". >> It is still possible to redirect Group0 interrupts from S-EL2 to EL3 and be handled there, but as said, this is a less preferred approach. >> >> Either way when NWd runs (with SCR_EL3.FIQ=1/IRQ=0), a Group1S/Group0 secure interrupt is trapped at EL3 and routed to SPMD then SPMC. >> The SPMC can take the decision to resume the secure partition which registered the corresponding secure INTID. >> >> This design does mean that SDEI interrupt handling would need SPMC and BL31 collaboration and this is something we are working on. > > I understood this scheme. But it means RAS interrupts and other > critical events will always have blackout periods even with proper > software design. RAS interrupts will have blackout periods even if a SMC is handled entirely in EL3. How is routing them to S-EL1 or S-EL2 any different? Afaiu, the RAS architecture spec does not lay down any time limits on by when an error must be reported. All RAS errors are not critical errors. Even critical errors e.g. uncontainable errors report something that has already happened. With unrecoverable errors, ESBs ensure that the problem is contained to a particular EL or Security state. Could you elaborate on what timing requirements you have and why a cooperative model would cause problems? > Whereas with the other routing model scheme the reliability of EHF > handlers can be retained with the constraint of PMR ranges. There may > be something > I am missing. I don’t think “reliability” is an argument here. It is about reusing the EHF in EL3. It is not off the table but we cannot overlook other evolutions in the software and hardware architecture since the EHF was written. Let me know what you think. Cheers, Achin > >> >> Hope this helps. >> >> 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: 28 September 2020 14:01 >> To: Sandeep Tripathy; Soby Mathew >> Cc: tf-a(a)lists.trustedfirmware.org; nd >> Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF >> >> Hi Sandeep, >> >> Your question is very valid and we're discussing options internally. >> >> We will come back to you with a consolidated answer shortly. >> >> Regards, >> Olivier. >> >> ________________________________________ >> From: Sandeep Tripathy >> Sent: Monday, September 28, 2020 05:28 >> To: Soby Mathew >> Cc: Dan Handley; tf-a(a)lists.trustedfirmware.org; nd; Olivier Deprez >> Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF >> >> >> Thanks Soby and Dan for confirmation on TSPD. I can see a few more gaps >> in the related area. >> >> "The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast >> SMC i.e. any execution context for that matter ". >> This should apply to all SPDs including SPMD. However I learned from >> @Oliver that SPMD/SPMC design traps FIQs to S_EL2. >> >> In that case a RAS interrupt can be masked by S_EL2 software (eg: >> Hafnium). Probably by design it will be ensured that S_EL2 will never >> mask the physical FIQ ? >> >> S_EL2 FIQ handler will exit to EL3/SPMD by SMC call. And depending on >> the pending interrupt type either it can exit to NWd OR invoke el3 fiq >> vector handler synchronously ? >> >> Are there limitations if we trap fiq to EL3 instead ? >> >> Thanks >> Sandeep >> On Fri, Sep 18, 2020 at 6:26 PM Soby Mathew <Soby.Mathew(a)arm.com> wrote: >>> >>> Hi Sandeep >>> >>>> Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). >>>> But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. >>>> EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. >>>> This is my understanding from the code please confirm if this is correct. >>> >>> The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. >>> >>>> EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. >>>> This is my understanding from the code please confirm if this is correct. >>> >>> You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. >>> >>> Best Regards >>> Soby Mathew >>> >>>> -----Original Message----- >>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep >>>> Tripathy via TF-A >>>> Sent: 17 September 2020 16:53 >>>> To: Dan Handley <Dan.Handley(a)arm.com> >>>> Cc: tf-a(a)lists.trustedfirmware.org >>>> Subject: Re: [TF-A] Query TSPD behavior with EHF >>>> >>>> Hi Dan, >>>> I am not sure if this is mentioned anywhere in any documents but I think >>>> EHF handlers should be able to preempt all execution contexts at lower ELs >>>> and lower ELs should never be able to mask such interrupts. >>>> If the behavioral expectation is set the implementation can be fixed. >>>> >>>> Thanks >>>> Sandeep >>>> >>>> On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- >>>> a(a)lists.trustedfirmware.org> wrote: >>>>> >>>>> A correction... >>>>> >>>>>> -----Original Message----- >>>>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan >>>>>> Handley via TF-A >>>>>> Sent: 17 September 2020 15:14 >>>>>>>> >>>>>>>> I want to handle something similar in OP-TEED along with EHF >>>>>>>> depending on >>>>>>> what is the expected behavior. >>>>>>>> >>>>>> Hmm, I thought OP-TEED was more like the >>>> TSP_NS_INTR_ASYNC_PREEMPT=0 >>>>>> case, where NS interrupts are routed to S-EL1 while processing a >>>>>> yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to >>>> follow? >>>>>> >>>>> Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are >>>> routed to EL3 first, but the TSPD re-enables NS interrupts before handing >>>> over to the TSP to handle yielding calls, via a call to >>>> ehf_allow_ns_preemption. >>>>> >>>> >>>> Right, that is the case for yielding SMC handling where both NS interrupts >>>> and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. >>>> But I would expect the same routing model even for 'Fast SMC' unlike what is >>>> happening in TSPD. >>>> >>>>> Dan. >>>>> >>>>> -- >>>>> TF-A mailing list >>>>> TF-A(a)lists.trustedfirmware.org >>>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>>> -- >>>> TF-A mailing list >>>> TF-A(a)lists.trustedfirmware.org >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >> >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A