Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: [email protected]
W: www.topicproducts.com
Please consider the environment before printing this e-mail
On 20-01-2021 14:57, Leon Woestenberg via lists.yoctoproject.org wrote:
Hello Mike,
On Wed, Jan 20, 2021 at 1:15 PM Mike Looijmans <[email protected]> wrote:
On 20-01-2021 11:45, Leon Woestenberg via lists.yoctoproject.org wrote:
...
For me it's still unclear what part of the steps are dependent on the
PL (Programmable Logic) design, I think the PMU configuration object
might be subject.
As far as I know - and daily practice confirms this - there's no
relation whatsoever between the PMU firmware and anything in PL or PS.
The PMU firmware is the same for all MPSoC boards. Nothing in the code
depends on the specific type of MPSoC chip or the configuration of PS or PL.
I was specifically talking about the PMU configuration object, not the
PMU firmware code. Once you start defining your own subsystems in the
power domain, at least the configuration object will change.
Then I think it depends on how you provide this object (linked-in, or
run-time provided at boot).
I would agree in most cases the subsystem domain split is "standard".
There is a "config object" sent to the PMU firmware by either SPL or
FSBL that sets a kind of "access rights" so you can configure that the
Thanks, I have found the documentation here:
Page 152 of
https://www.xilinx.com/support/documentation/user_guides/ug1137-zynq-ultrascale-mpsoc-swdev.pdf
The simplest solution was to just offer the PMU firmware as a binary
download. That's what we've been using internally for years now. Just
build it once with either yocto or Xilinx' toolchain, and keep the binary.
Thanks for confirming. How have you been dealing with the PMU
configuration object in that setting? Using U-Boot-SPL?
So far I've just compiled it in. One configuration is enough for a dozen
boards, so they can all share the same binary.
Support for the config object is now part of u-boot SPL, so there's no
dependency on the Xilinx tools there.
Explicitly partitioning the system becomes interesting when building in
some safety features, so a bug in the R5 code won't overwrite a part of
your kernel or mess up some peripheral it wasn't supposed to touch. That
would make the config file project specific. The PMU firmware binary
would still remain identical across all boards.
I prefer to have a bootloader that is independent of the application I
want to run on the board. That ensures that the board will always boot,
even if you flip the power switch halfway through a firmware upgrade...
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4813):
https://lists.yoctoproject.org/g/meta-xilinx/message/4813
Mute This Topic: https://lists.yoctoproject.org/mt/79922814/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
