Re: [meta-xilinx] Booting zcu102-zynqmp machine crashes in SPL
Hi Sebastian,
Please see (SPL flow section )
https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/README.building.md
Thanks,
Manju
From: meta-xilinx-boun...@yoctoproject.org
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Sebastian Panceac
Sent: Friday, March 08, 2019 1:16 AM
To: meta-xil...@lists.yoctoproject.org
Subject: [meta-xilinx] Booting zcu102-zynqmp machine crashes in SPL
Hi,
I'm using the `meta-xilinx` layers to build the OS for the Xilinx ZCU102 board:
https://www.xilinx.com/products/boards-and-kits/ek-u1-zcu102-g.html board.
I compiled for the "zcu102-zynqmp" Yocto machine.
In order for u-boot to build successfully I had to rename the symbolic link
from "${DEPLOYDIR}/pmu-firmware-${MACHINE}.bin" to
"${DEPLOYDIR}/pmu-${MACHINE}.bin" in the "do_install" task of
"pmu-firmware_2017.3.bb recipe".
I used the "rel-v2018.3" branch of meta-xilinx.
I flashed a SD card with the boot files according to:
https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/README.booting.md#loading-via-sd
but the boot process hangs in SPL with this stack trace:
Debug uart enabled
"Synchronous Abort" handler, esr 0x9640
ELR: fffcaa3c
LR: fffc774c
x0 : fdfd00011dfd0060 x1 :
x2 : 02020202ffa0 x3 : 2000
x4 : fdfd00011dfd0068 x5 :
x6 : 00405fffe0405ff4 x7 : 2008
x8 : 00ad x9 : 0080
x10: fffd x11: 0064
x12: fe6a x13: 098100080102
x14: ca99010442042023 x15: 0020890800101045
x16: 0001284017244083 x17: 002011001c040041
x18: 7e90 x19: 2000
x20: x21: fdfd00011dfd0060
x22: x23: 0001
x24: 7f20 x25: fffdaca8
x26: fffdb000 x27: fffd977a
x28: x29: 7c10
Resetting CPU ...
### ERROR ### Please RESET the board ###
Also, is it mandatory to compile also "pmu-rom" for this board to boot?
Please advise! Thanks!
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] ZCU102 boot issue
On 07-03-19 21:54, Manjukumar Harthikote Matha wrote: > Hi Mike, > >> -Original Message- >> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx- >> boun...@yoctoproject.org] On Behalf Of Mike Looijmans >> Sent: Friday, February 01, 2019 12:19 AM >> To: meta-xilinx@yoctoproject.org >> Subject: Re: [meta-xilinx] ZCU102 boot issue >> >> On 30-01-19 14:13, Jean-Francois Dagenais wrote: >>> Hi guys, >>> On Jan 28, 2019, at 14:39, Manjukumar Harthikote Matha mailto:manju...@xilinx.com>> wrote: Hi Alex, You need additional patches on pmu-firmware See:https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January /004198.html >>> >>> Manju, thanks for your patience and diligence in answering this yet another >>> time. >>> >>> In my experience, when such an issue is raised again and again, it >>> means it will not go away and it costs a lot in loss of time, money >>> and most importantly, spirit ;) >>> >>> I know it's been discussed before too but if I may add my 2 cents: Am >>> I missing something or without manually patching pmu-firmware, the >>> boards in the meta-xilinx-bsp will not function because of the missing >>> config object? (I still use meta-xilinx-tools so I actually don't >>> know.) Doesn't this mean Xilinx doesn't fully support the open-source >>> workflow? Or is just the word "support" that should be replaced with >>> "participates"? (In which case it is indeed directly responsible for >>> it) >>> >>> I remember problems with the licensing, but there has to be a >>> solution. Even if not elegant, once automated in yocto recipes, it's >>> better than nothing and a broken board after 5 hours of building! >>> >>> And if this is still not possible, to help people find the very >>> un-obvious source of their issues, perhaps PMU firmware could suffix >>> "(no cfg obj)" to its version? Or anything else printed early which >>> will help people find a xilinx wiki page explaining the problem and the >>> solutions >> available. >>> >> >> Simplest solution here would be to just integrate that "default config" >> patch into the >> standard PMU firmware and then all boards will just boot. It won't prevent >> the FSBL >> changing the config, so that flow isn't affected negatively. >> > > Please do send a patch if you have for pmu-firmware "default config". We will > take a look at having them integrated. It's where it's always been: https://github.com/topic-embedded-products/meta-topic/tree/master/recipes-bsp/pmu-firmware/pmu-firmware -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] Booting zcu102-zynqmp machine crashes in SPL
Hi,
I'm using the `meta-xilinx` layers to build the OS for the Xilinx ZCU102
board: https://www.xilinx.com/products/boards-and-kits/ek-u1-zcu102-g.html
board.
I compiled for the "zcu102-zynqmp" Yocto machine.
In order for u-boot to build successfully I had to rename the symbolic link
from "${DEPLOYDIR}/pmu-firmware-${MACHINE}.bin" to
"${DEPLOYDIR}/pmu-${MACHINE}.bin" in the "do_install" task of "
pmu-firmware_2017.3.bb recipe".
I used the "rel-v2018.3" branch of meta-xilinx.
I flashed a SD card with the boot files according to:
https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/README.booting.md#loading-via-sd
but the boot process hangs in SPL with this stack trace:
Debug uart enabled
"Synchronous Abort" handler, esr 0x9640
ELR: fffcaa3c
LR: fffc774c
x0 : fdfd00011dfd0060 x1 :
x2 : 02020202ffa0 x3 : 2000
x4 : fdfd00011dfd0068 x5 :
x6 : 00405fffe0405ff4 x7 : 2008
x8 : 00ad x9 : 0080
x10: fffd x11: 0064
x12: fe6a x13: 098100080102
x14: ca99010442042023 x15: 0020890800101045
x16: 0001284017244083 x17: 002011001c040041
x18: 7e90 x19: 2000
x20: x21: fdfd00011dfd0060
x22: x23: 0001
x24: 7f20 x25: fffdaca8
x26: fffdb000 x27: fffd977a
x28: x29: 7c10
Resetting CPU ...
### ERROR ### Please RESET the board ###
Also, is it mandatory to compile also "pmu-rom" for this board to boot?
Please advise! Thanks!
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [meta-xilinx-tools][RFC] device-tree.bbappend: Changes needed to use upstream devicetree class
Hi Luca,
> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Wednesday, February 27, 2019 12:04 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@yoctoproject.org; Jaewon Lee
> Subject: Re: [meta-xilinx] [meta-xilinx-tools][RFC] device-tree.bbappend:
> Changes
> needed to use upstream devicetree class
>
> Hi Manjukumar, Jaewon,
>
> On 26/02/19 04:07, Manjukumar Matha wrote:
> > From: Jaewon Lee
> >
> > These are some changes needed to use upstream devicetree class. There
> > are some variable name changes as well as switching some script to
> > python from bash.
> >
> > Signed-off-by: Jaewon Lee
> > Signed-off-by: Manjukumar Matha
> > ---
> > recipes-bsp/device-tree/device-tree.bbappend | 23 +++
> > 1 file changed, 11 insertions(+), 12 deletions(-)
> >
> > diff --git a/recipes-bsp/device-tree/device-tree.bbappend
> > b/recipes-bsp/device-
> tree/device-tree.bbappend
> > index e077955..118688c 100644
> > --- a/recipes-bsp/device-tree/device-tree.bbappend
> > +++ b/recipes-bsp/device-tree/device-tree.bbappend
> > @@ -44,10 +44,10 @@ YAML_DT_BOARD_FLAGS_zcu104-zynqmp ?= "{BOARD
> zcu104-revc}"
> > YAML_DT_BOARD_FLAGS_zcu111-zynqmp ?= "{BOARD zcu111-reva}"
> > YAML_DT_BOARD_FLAGS_zc1275-zynqmp ?= "{BOARD zc1275-revb}"
> >
> > -DTS_FILES_PATH = "${XSCTH_WS}/${XSCTH_PROJ}"
> > -DTS_INCLUDE_append = " ${WORKDIR}"
> > +DT_FILES_PATH = "${XSCTH_WS}/${XSCTH_PROJ}"
> > +DT_INCLUDE_append = " ${WORKDIR}"
> > DT_PADDING_SIZE = "0x1000"
> > -KERNEL_DTS_INCLUDE_append = " ${STAGING_KERNEL_DIR}/include"
> > +KERNEL_INCLUDE_append = " ${STAGING_KERNEL_DIR}/include"
> >
> > COMPATIBLE_MACHINE_zynq = ".*"
> > COMPATIBLE_MACHINE_zynqmp = ".*"
> > @@ -57,21 +57,20 @@ SRC_URI_append_ultra96-zynqmp =
> "${@bb.utils.contains('MACHINE_FEATURES', 'mipi'
> >
> > do_configure_append_ultra96-zynqmp() {
> > if [ -e ${WORKDIR}/mipi-support-ultra96.dtsi ]; then
> > - cp ${WORKDIR}/mipi-support-ultra96.dtsi
> > ${DTS_FILES_PATH}/mipi-
> support-ultra96.dtsi
> > - echo '/include/ "mipi-support-ultra96.dtsi"' >>
> ${DTS_FILES_PATH}/system-top.dts
> > + cp ${WORKDIR}/mipi-support-ultra96.dtsi
> > ${DT_FILES_PATH}/mipi-
> support-ultra96.dtsi
> > + echo '/include/ "mipi-support-ultra96.dtsi"' >>
> ${DT_FILES_PATH}/system-top.dts
> > fi
> > }
> >
> > -
> > -do_compile_prepend_kc705-microblazeel() {
> > - cp ${WORKDIR}/system-conf.dtsi ${DTS_FILES_PATH}
> > - cp ${WORKDIR}/kc705-microblazeel.dts ${DTS_FILES_PATH}
> > -}
>
> The log message does not explain why this change it is needed. It also
> looks unrelated to the rest of the changes so it might be worth a
> separate commit.
>
The upstream class moved to python based from bash functions. We cannot move it
to a different patch, we can explain better in the commit message
> > do_compile_prepend() {
> > - [ -e ${DTS_FILES_PATH}/system.dts ] && rm ${DTS_FILES_PATH}/system.dts
> > +listpath = d.getVar("DT_FILES_PATH")
> > +try:
> > +os.remove(os.path.join(listpath, "system.dts"))
> > +except OSError:
> > +pass
>
> Oh dear, Python is usually very concise but there are clearly
> exceptions. Any python expert knows a more concise way to do 'rm -f
> $FILE' in python? Otherwise of course this code is OK.
>
I think there is a better way than this one, we are looking into it
Thanks for feedback.
Thanks,
Manju
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
