Hi Steve,
I would say there is nothing wrong in your patch. Except the approach your
are using to boot UEFI on your platform might not be appropriate. Making
these two PCDs pointing into System Memory is not the way there are expected
to be used.
PcdCPUCoreSecStackBase and PcdCPUCoresStackBase (and SEC & PeiCore) should
only be used when EDK2 is started in Secure World and before the (permanent)
system memory (DRAM) is initialized.
PcdCPUCoreSecStackBase should point somewhere into your Secure RAM. And
PcdCPUCoresStackBase should point somewhere into your temporary memory (eg:
SRAM).
If your platform has a Secure/Trusted Firmware then you should not use
ArmPlatformPkg/Sec into your UEFI firmware. Your firmware should start after
the SEC phase.
ArmPlatformPkg/Sec has been implemented to initialize the Secure World.
Running this module in Non-Secure world is not correct.
To get a proper implementation of a Trusted/Secure Firmware on ARMv8
platform, you should have a look at the ARM Trusted Firmware Open SOurce
project: https://github.com/ARM-software/arm-trusted-firmware
If you know what you are doing and still want to use ArmPlatformPkg/Sec,
then there is a chance your Secure RAM is into your 32bit address space
(even if your memory map is bigger than 4GB).
PEI Core is designed to start from XIP memory and used temporary memory. A
PEIM module is expected to initialize your permanent system memory. PEI Core
would then pass control to the DXE phase.
PEI Core relocates itself from temporary memory to permanent memory during
its execution. So starting PEI Core from permanent memory means the module
will copy itself into permanent memory again.
On most ARM Platforms, UEFI starts as a secondary stage boot loader (the
Trusted Firmware being the first stage). To prevent this non-required copy,
I introduced ArmPlatformPkg/PrePi that does the required PI initialization
and pass control to the DXE core.
The drawback of ArmPlatformPkg/PrePi is it does not support PEIMs. But it is
acceptable in most cases.
Again, generally your temporary memory (eg: SRAM) is in your first 4GB of
your address space.
What I want to say is - yes, there is nothing wrong to make
PcdCPUCoreSecStackBase and PcdCPUCoresStackBase 64-bit PCDs. But the reason
to use these PCDs might not be valid in your case.
Have a look at this page for additional information:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPlatformP
kg
Let me know if my email is clear enough or if you need further explanation.
I would like to reuse the content in the wikipages.
Thanks,
Olivier
From: Steven Kinney [mailto:[email protected]]
Sent: 21 February 2014 17:32
To: [email protected];
[email protected]
Subject: [edk2] [RFC] ArmPlatformPkg: PcdCPUCoreSecStackBase and
PcdCPUCoresStackBase: UINT64 (patch)
Hi Olivier,
I modified the Stacks so that the typedef is UINT64;
for pointing to System Memory outside of the addressable region accessable
via UINT32. This is very similar to the System Memory changes you made
regarding System Memory base address earlier. I can across this issue when
migrating to our silicon memory map, which has the stacks in DRAM outside of
the addressable range afforded by a UINT32 typedef. Please suggest changes
or considerations I might have overlooked. I tested this on AARCH64 across
multiple memory regions; including the RTSM SRAM locations.
Thanks,
Steve
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
